Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common mistakes writing React components with hooks

lorenzweiss.de

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Common mistakes writing React components with hooks

#71

Post by brlewis »

tekkk wrote: post #40

A recent thing which has been rubbing me the wrong way in React has been the exhaustive dependencies for useEffect and other hooks. Sure, in the case someone would alter say the function provided as props it should be included in the dependency array. Yet in most cases, such as the example #3 in the article, this would not happen (or be even desired). Rather, if it did it would be a bug and an appropriate error would…

There is no harm in adding something to the dependency array that you don't expect to ever change. The linter is your friend; make its job easier.

Re: Common mistakes writing React components with hooks

#72

Post by vvpan »

evan_ wrote: post #62
vvpan wrote: post #60

I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…

I would ignore whoever told you not to use an empty array for the dependency argument. Change your linter rules. It's fine.

That's good to hear!

Re: Common mistakes writing React components with hooks

#73

Post by evan_ »

brlewis wrote: post #67
evan_ wrote: post #62

Earlier quoted context omitted.

I would ignore whoever told you not to use an empty array for the dependency argument. Change your linter rules. It's fine.

That runs the risk of someone less experienced introducing a bug later when a new dependency is introduced. I think it's better to simply do whatever the linter says.

There's also a risk that someone less experienced hits themselves in the thumb with a hammer, and then hits themselves between the eyes with the claw, and then drops the hammer on their foot.

Re: Common mistakes writing React components with hooks

#74

Post by cellar_door »

tekkk wrote: post #40

A recent thing which has been rubbing me the wrong way in React has been the exhaustive dependencies for useEffect and other hooks. Sure, in the case someone would alter say the function provided as props it should be included in the dependency array. Yet in most cases, such as the example #3 in the article, this would not happen (or be even desired). Rather, if it did it would be a bug and an appropriate error would…

I mean, onSuccess could change. And as you suggested, creating the extra callback is redundant.

  const fetchData = () => {
    setLoading(true);
    callApi()
      .then((fetchedData) => {
        setData(fetchedData);
        onSuccess();
      })
      .catch((err) => setError(err))
      .finally(() => setLoading(false));
  };
  useEffect(() => {
    fetchData();
  }, []);
becomes

  useEffect(() => {
    setLoading(true);
    callApi()
      .then((fetchedData) => {
        setData(fetchedData);
        onSuccess();
      })
      .catch((err) => setError(err))
      .finally(() => setLoading(false));
  }, [onSuccess]);

Re: Common mistakes writing React components with hooks

#75

Post by jgwil2 »

bauerd wrote: post #4

Nitpick, but React is not a framework, it's a library. People miss this point often eg when they compare React to Angular

React's documentation calls it a library but we don't have to. I think the reason people go back and forth on this is that there are a couple definitions of framework out there. A lot of people consider it to be a sort of continuum, where a library becomes framework-like as it adds more and more functionality. I understand that framework can sometimes connote bloat, which is probably why the React docs avoid the term. And I think it's perfectly reasonable to say that frameworks are a subset of libraries, so perhaps they're not strictly wrong to describe React as a library.

But, as others have pointed out in this thread, a much more useful distinction is where the library's code gets called in the stack. If your code is at the top of the call stack with library code below it, then it's a framework. If their code is at the top, then it's a library. In short, you call a library, a framework calls you (inversion of control). So in that sense React is most definitely a framework.

Also, I'm willing to be wrong on this one if somebody can give me a meaningful and objective reason that React should be considered a library but Angular should be considered a framework.

Re: Common mistakes writing React components with hooks

#76

Post by brlewis »

evan_ wrote: post #73
brlewis wrote: post #67

Earlier quoted context omitted.

That runs the risk of someone less experienced introducing a bug later when a new dependency is introduced. I think it's better to simply do whatever the linter says.

There's also a risk that someone less experienced hits themselves in the thumb with a hammer, and then hits themselves between the eyes with the claw, and then drops the hammer on their foot.

Are you saying that writing code in a way that defends against future mistakes is a waste of time? It's hard to see the content of your comment through the sarcasm.

Re: Common mistakes writing React components with hooks

#77

Post by evan_ »

brlewis wrote: post #76
evan_ wrote: post #73

Earlier quoted context omitted.

There's also a risk that someone less experienced hits themselves in the thumb with a hammer, and then hits themselves between the eyes with the claw, and then drops the hammer on their foot.

Are you saying that writing code in a way that defends against future mistakes is a waste of time? It's hard to see the content of your comment through the sarcasm.

I do think that's important. I practice that by writing readable, well-formatted code, commenting liberally, and avoiding "too-clever" hacks. I don't think using a well-documented feature for the purpose it was intended violates any of these.

Re: Common mistakes writing React components with hooks

#78

Post by lumens »

vvpan wrote: post #60

I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…

I found this article incredibly helpful in answering these questions: https://overreacted.io/a-complete-guide-to-useeffect/

Re: Common mistakes writing React components with hooks

#79

Post by brlewis »

evan_ wrote: post #77
brlewis wrote: post #76

Earlier quoted context omitted.

Are you saying that writing code in a way that defends against future mistakes is a waste of time? It's hard to see the content of your comment through the sarcasm.

I do think that's important. I practice that by writing readable, well-formatted code, commenting liberally, and avoiding "too-clever" hacks. I don't think using a well-documented feature for the purpose it was intended violates any of these.

Is the well-documented feature the dependency array or the ability to suppress linter rules? The note at the bottom of the documentation section for the dependency array recommends using the linter rule: https://reactjs.org/docs/hooks-effect.html#tip-optimizing-pe...

Re: Common mistakes writing React components with hooks

#80

Post by WesleyJohnson »

sickcodebruh wrote: post #64
vvpan wrote: post #60

I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…

If you need an effect to run before the component draws, try `useLayoutEffect` instead of `useEffect`. https://reactjs.org/docs/hooks-reference.html#uselayouteffec...

How do you handle a useEffect that relies on state, but you don't want it to run on first render? I usually have a separate state that is "firstLoad" and toggle that in the effect and exit out, then its free to run on successive invocations. But typing this out - it makes me the think the dependent state itself should be driving if it runs or not...
Post reply on HN