Hacker News Reader

> To avoid unnecessary re-rendering you’ll have to move callbacks into useCallback. These callbacks then also need to specify all of their dependencies. So many lines of code that are merely noise.

I really like Vue 3’s Composition API as a much easier-to-use (IMO) implementation of hooks.

It’s conceptually very similar to React Hooks, but the method that defines them only runs once, when the component is instantiated. So straight away that removes any worries around conditionals and loops.

Instead of a plain value/object and an update function, the “hooks” instead return a reactive object that tracks it’s own dependencies (which are also all reactive objects). That removes any need to manage dependencies yourself, or for any memoization.

The only downside is that because a plain value (like a number or something) cannot be reactive, it has to be wrapped in an object and accessed via a “.value” property, but this is only relevant in the setup function. Anywhere else, like the Options API or in the template, accessing the value like a value will just get transparently proxied to the object.

The entire concept of reactive objects brings back memories of extreme pain from KnockoutJS days (and terrible performance in complex scenarios to boot). I prefer just working with plain old data structures.

I prefer working with just plain old setup functions, that are called once.

I find React and Vue to be different expressions of the same core concept in a way. Althoguh I do prefer the functional nature of React, reactive objects are a lot less boilerplate, even if it might be a bit slower. The composition api itself is actually I think where it shines, because the options API is very mediocre in my opinion.

Is it actually slower though? I feel like that’s Vue’s entire marketing strategy. “We’re just as fast and small as React but include way more out of the box and it’s easier to grok for new people”.

My experience is mixed but mostly positive.

- Agreed about useState (and useReducer). They’re simple and they get the job done.

- Agreed about useCallback as well, it’s a lot of boilerplate.

- State in general is a hard problem to deal with, but I’m not sure how hooks in particular encourage it? Class components had the same issue.

- IMO, useEffect is a huge footgun. I understand how it works, I understand how closures work, but it is by far the biggest source of hook-related bugs I’ve experienced.

- This eslint plug-in will solve your dependency list woes: https://www.npmjs.com/package/eslint-plugin-react-hooks

+1 for that eslint plugin, I was just idly wondering if something like that existed earlier this week. Thanks.

Unless your app is peculiar in some way I’d recommend using something like Create React App, which includes it automatically. https://create-react-app.dev

> If you want something to execute once initially you can use useEffect with an empty dependency list, but note that then there’s no way of accessing updates values (in callbacks) and everything will reflect the initial state. Often you’ll have to use useRef just to keep track of the current state. Or maybe useState?

I'm not sure if I understood what you mean, but note that useState accepts not only the updated state, but also a function that takes the current state as argument and return the updated state.

In other words, instead of something like this

useEffect( async () => {

  ...

  const someValue = await someFunction();

  setState({...state, someValue });

}, [... ] );

you should use something like this

useEffect( async () => {

  ...

  const someValue = await someFunction();

  setState( currentState => ({...currentState, someValue }));

}, [ ... ] );

(the example is with async but it is the same for regular callbacks)

Note that you shouldn’t (can’t?) actually pass an async function directly to useEffect, since it returns a promise: https://github.com/facebook/react/issues/14326

Not true, see Gaeron's direct reply in the thread you linked to, that's been the standard for 3 years and works like a charm - useEffect specifically is the hook for handling async functions ("impure effects").

Notice the words "pass to useEffect" in the parent comment, and the code snippet in the grandparent they are commenting on. The type of the callback function that useEffect accepts is () => void rather than () => Promise<unknown>. What's not true about that?

I reworded it to make it a bit more clear (at least, I thought so) — "pass an async function to useEffect", meaning the argument supplied to useEffect itself, rather than "use directly within" which is ambiguous. Re-added "directly" to hopefully make even more clear. Sorry for the confusion!

I usually use an IIFE to encapsulate the async block inside the useEffect. Works like a charm!

True, you cannot do that in useEffect, it will throw you error. And probably your linter will tell you. You can't even use your own or third party hooks in side useEffect. This also throw error I don't know why?

Because you could be nesting hooks, which would bring all sorts of weird behavior.

you're right, good catch. Usually it's the TS compiler that prevents me doing that.

You can use a boolean ref for this in the useEffect to keep track whether it was the first render or not. https://reactjs.org/docs/hooks-faq.html#can-i-run-an-effect-...

> Debugging is painful. You forget one value in your dependency list and the weirdest things happen

This should never happen. The only downside to hooks is that the eslint plugin is _required_, not optional. It is not worth the pain without it, but you'll be in a Whole New World once you do it. Since you can auto-fix every time, it'll become second nature and you'll never forget a dependency again. You can focus on getting your application to work.

>You forget one value in your dependency list and the weirdest things happen.

This is what I hate in angular1 , there are at least 3-4 ways you can mess up a simple data-binding and there is no error or warning to inform you that something is not right so you waste a lot of time to figure it out.

I used react a few years back but it seems that this days it got hyper complex.

As far as I can tell you can just not use hooks, if you (and the rest of your contributors) agree.

> You forget one value in your dependency list and the weirdest things happen.

Don't you get eslint warnings right in your editor?

If you're using VS Code there's an extension for that...

Not only this but I need the freedom to control the dependency list for an effect. Sometimes it isn't as simple as "every variable being referenced inside the effect."

that's a bit confusing. While you can sometimes get away with leaving out dependencies, and then you don't have to useMemo or useCallback as often, it seems like there is a much larger downside to having potentially stale values in your effect. Leaving them out to me would result in the potential for weird future bugs and race conditions.

>but note that then there’s no way of accessing updates values (in callbacks)

This is by design. When you start making a component worry about what it needs to do on an update, rather than just rendering its data, you are introducing a whole new level of complexity. That's why class based React components could turn into these unwieldy confusing things where you never knew for certain what was going to render every time, because the shouldComponentUpdate method gets stuffed full of business logic.

Regarding useCallback, you can probably skip it in most cases, unless the extra renders are a problem for you.

Linters should help with missing dependencies.

Yes! useCallback is an optimization and using it prematurely can be problematic.

You can use OOP or whatever you want to build your abstraction and then surface that as a hook, rather than using hooks as a way to do all your logic. This is similar to how there are npm packages that just import some other js package “foo”, wrap its api in a react component, and reexport it as react-foo

I’m curious what you think of https://rxstore.dev/ it basically is a pattern I tried to outline where you write logic with rxjs and it tries to bridge the gap to react/hooks for you. I address some of your points in the faq.

> You forget one value in your dependency list and the weirdest things happen.

There's an eslint plugin specifically for detecting this, which should probably be considered mandatory.

> You forget one value in your dependency list and the weirdest things happen

Really? I've been working with hooks for months, with code in production, and I hardly ever pass more than one or two items to the dependency list. The only time I really had any trouble with dependencies was when I was updating appContext inside a hook.

Seconded. Plus, you start writing wrapper functions for standard Javascript APIs (e. G. window.setInterval) to force them into Reacts data model.

Why would you do that? What’s wrong with this?

    useEffect(() => {
      const interval = setInterval(myFunc, 1000)
      return () => clearInterval(myInterval)
    },[])

I think one of the keys to React is not to fear the boilerplate.

If you find yourself typing the same code too often, there’s probably a higher level abstraction that you should find, way above the level of setInterval.

I find coders often try to DRY up low level code to the detriment of actually dealing with their _application_ architecture.

In general, you should use the tools as provided, boilerplate and all, and then focus your real brain energies on the specific domain problems that only your application needs.

Creating thin wrappers on external tools to squeeze the last tiny bits of DRYness is not only usually a waste of time, but it makes your code unreadable. People know how setInterval and useEffect work. If I see useInterval I have to go read your code to know what’s happening. Especially if you made it configurable. And people _will_ tend to add configuration to these wrappers over time as needs change.

in my experience is better to have customs hooks like useTimeout (react-use library is awesome) so is easier to test. Mocking hooks feels nice, mocking the browser API not so much...

... which is a good idea anyway because you want your code to be testable.