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

51–60 of 98 posts

Re: Common mistakes writing React components with hooks

#51

Post by [deleted] »

brlewis wrote: post #50
steinuil wrote: post #15

The first one just feels like a premature optimization. Yes calling setCount forces a rerender of that component, but unless there's lots of subcomponents inside that component, I wouldn't bother. Chances are later you'll need that state in the view, and if you have "unexpected side effects" from rerendering then that is the problem. The other tips are fine; effects should have a single responsibility and links and b…

Yes. The author should replace "This is dangerous" with "This is a tiny bit sub-optimal" in the first example. EDIT: "This is dangerous" is also the wrong label for the 2nd example. Should be "This is not the cleanest way" EDIT2: "This is dangerous" is also the wrong label for the 3rd example. Should be "This is not the most readable". I'd also note that I'm surprised the author has seen this mistake a lot; the "solu…

[deleted]

Re: Common mistakes writing React components with hooks

#52

Post by pg_bot »

qudat wrote: post #33
pg_bot wrote: post #8

I would argue that writing a React component with a hook is a mistake. There is usually an easier/clearer way to solve the problems that hooks are intended to solve with the existing React primitives.

I get what you're saying but disagree. Hooks are essential and make life much easier for the react developer, especially when using something like `react-redux` or `react-router`. Prop-drilling or HoC might seem like a better design until you actually have to work in a system that leverages them and realize it's an indirection nightmare.

I would go a step further and say that React Components should not manage their state internally. (this.state was a mistake to add to the project) You can create every single UI in the world using pure functional components. They are easier to understand since they act like every other function, and they are simpler to test.

Keep your state externally and just grab what you need on each subcomponent with the `connect` function from `react-redux`. Easy peasy front-end development.

Re: Common mistakes writing React components with hooks

#53

Post by dntrkv »

jfkebwjsbx wrote: post #39
vishnu_ks wrote: post #18

Earlier quoted context omitted.

What is difference between a front-end library and a front-end framework?

A library is added to a project. A project is added to a framework.

I agree with this definition.

So how is React a library? You can't just utilize part of React within an existing Angular app. I've built shims between the two frameworks and you can't just use React inside of Angular. When you utilize a React component inside of Angular, everything Angular about the application goes out the window and it becomes a mini React app starting from that component, just with the data originating from an Angular app.

The definition of a framework boils down to inversion of control, right? You define your application, and then it is run within the React "framework" context, which calls various predefined methods/functions.

All of the lifecycle methods in React are a good indicator, to me, that it is indeed a framework. You define these functions, and they are called by the framework. Inversion of control.

Re: Common mistakes writing React components with hooks

#54

Post by enumjorge »

jiofih wrote: post #49
nicoburns wrote: post #10

Earlier quoted context omitted.

To me, the killer feature of React is how easy it is to mix with standard "vanilla" JS libraries. The "React" version of a library is usually a fairly trivial wrapper around the "normal" version. In contrast, integrating with Angular is a lot more involved and is in effect its own ecosystem. The other thing I can't stand about Angular is that it puts its proprietary templating language "in control" of components. Whi…

Can you provide some examples? My experience is that almost any library you end up using is built specifically for React and not vanilla.

Redux can be used in projects unrelated to React.

Re: Common mistakes writing React components with hooks

#55

Post by vvpan »

brlewis wrote: post #50
steinuil wrote: post #15

The first one just feels like a premature optimization. Yes calling setCount forces a rerender of that component, but unless there's lots of subcomponents inside that component, I wouldn't bother. Chances are later you'll need that state in the view, and if you have "unexpected side effects" from rerendering then that is the problem. The other tips are fine; effects should have a single responsibility and links and b…

Yes. The author should replace "This is dangerous" with "This is a tiny bit sub-optimal" in the first example. EDIT: "This is dangerous" is also the wrong label for the 2nd example. Should be "This is not the cleanest way" EDIT2: "This is dangerous" is also the wrong label for the 3rd example. Should be "This is not the most readable". I'd also note that I'm surprised the author has seen this mistake a lot; the "solu…

Yeah, there are gotchas and issues with hooks and some of them are quiet common but this article does not cover those. Odd selection of "mistakes".

Re: Common mistakes writing React components with hooks

#56

Post by 6gvONxR4sf7o »

The router vs link one drives me crazy. I usually browse via tabs, reading breadth first rather than depth first (finish a page then read its interesting links, rather than reading links as I encounter them). Single page apps that don't let you open links/buttons in new tabs make that impossible. It frustrates the hell out of me.

Re: Common mistakes writing React components with hooks

#57

Post by LorenzA »

pg_bot wrote: post #52
qudat wrote: post #33

Earlier quoted context omitted.

I get what you're saying but disagree. Hooks are essential and make life much easier for the react developer, especially when using something like `react-redux` or `react-router`. Prop-drilling or HoC might seem like a better design until you actually have to work in a system that leverages them and realize it's an indirection nightmare.

I would go a step further and say that React Components should not manage their state internally. (this.state was a mistake to add to the project) You can create every single UI in the world using pure functional components. They are easier to understand since they act like every other function, and they are simpler to test. Keep your state externally and just grab what you need on each subcomponent with the `connect…

not sure i understand you correctly, but keeping all state external just clutters up the store i feel. if the state is not used anywhere else and you also don't need to change it externally i would not move state out of the component. also if your state is always outside of your component they will only be reusable if you hook up the store in all your projects the same way

Re: Common mistakes writing React components with hooks

#58

Post by kin »

These are good points, but the examples are an oversimplification and can present problems if overlooked.

In the examples, if a function is only ever called within one hook callback, it should just be defined in that hook callback. Doing so would expose what you're missing in your dependency array.

Re: Common mistakes writing React components with hooks

#59

Post by rejschaap »

jiofih wrote: post #49
nicoburns wrote: post #10

Earlier quoted context omitted.

To me, the killer feature of React is how easy it is to mix with standard "vanilla" JS libraries. The "React" version of a library is usually a fairly trivial wrapper around the "normal" version. In contrast, integrating with Angular is a lot more involved and is in effect its own ecosystem. The other thing I can't stand about Angular is that it puts its proprietary templating language "in control" of components. Whi…

Can you provide some examples? My experience is that almost any library you end up using is built specifically for React and not vanilla.

I have used react-sortablejs and react-leaflet in the past. I don't have any experience actually wrapping existing libraries myself though.

https://github.com/SortableJS/react-sortablejs

https://react-leaflet.js.org/

Re: Common mistakes writing React components with hooks

#60

Post by vvpan »

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 useCallback then that'd be proper, but can't imagine the value. I think most of the internet simply does empty dependency and ignores what creators of hooks suggest.

* I want to run things before the component mounts, like API calls.

* I often want my useEffect to trigger when only one of the state variables it references is updated. Again, linter screams at me and I add an exception.

* Because useEffect triggers after component mounts, and only then, it's sometimes difficult to avoid some flicker. For example I want to do something when a components prop (say "loading") changes from "true" to "false". Loading has finished, prop has been updated, component re-rendered, and only then I can trigger what I really wanted to do on that transition. I think "componentWillReceiveProps" would have solved this, but there is no functional equivalent.

Basically if there is a person who uses "useCallback" out there "correctly" I have not met them yet. My junior subordinates misuse useEffect quiet often. I often see (and use) empty dependency arrays. I see (and use) partial dependency arrays, often adding linter exceptions. Reading articles about "proper" ways of doing it sorta makes sense but it is easy to forget what the hooks authors really meant.

I think hooks is a good feature, but the authors made too many assumptions when developing them. There is a philosophy underlying them but that philosophy is somewhat incongruent with the philosophy of "I just want to get this done". React is just one tool, I have 20 more things to do every day and understanding the full philosophy of functional dependencies and when and how to properly use "useCallback" - I just do not have time, and junior devs get confused even more.

Post reply on HN