4 ms·

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times still find myself confused by hooks or the mess that I create when I use them.

bryanrasmussen 5y ago
In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing number of hooks to make everything hang together.
- seer 5y ago
  Maybe, but in my experience whenever I encounter an incomprehensible mess of hooks it usually ends up because devs were not using all the tools that react provides. For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer. Components that don’t benefit much from splitting up could have their business logic wrapped into a context, and let the view code be just jsx without all the interweaving of code and templates. Maybe the one benefit of classes was like it forced you to think in business logic, then render. React still has that, you just need to dive a bit deeper into its toolbox. The result usually turns out much more flexible - contexts neatly wrap business logic for all of its descendants, classes don’t. I think this was maybe because react actually allows you to write messy code, and it’s still performant and works. But in the end it just kinda postpones the inevitable maintenance burden. I guess solid.js from the looks of it might postpone it a bit more. I just worry that solid looks more like magic, and some invariant somewhere will just break and I wouldn’t know what sequence of reactions actually led to that infinite loop that crashed the page. Haven’t tried it myself though, might more understandable in the end…
  - ricardobeat 5y ago
    > For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer You've just deoptimized your app, and your whole component will re-render on every change. > Components that don’t benefit much from splitting up could have their business logic wrapped into a context You did it again. More unnecessary re-renders. > it’s still performant and works True that 'it works', but it's usually not as performant as you think - we just have really fast computers and phones now.
    - littlecranky67 5y ago
      Why is performance always argument No. 1? The true rule is, code must be readable and maintainable first. THEN, if there are performance issue with the code (no theoretical ones, you HAVE to have a real-world profiling report of YOUR code in your hands when you argue about performance), you can refactor for performance.
      - mst 5y ago
        A thing I remind myself of regularly: Avoiding worrying about optimisation up front too much is not avoiding caring about optimisation at all, it's reserving the number of hours you can expend on optimisation until you have enough working to have a profile available, because you are inevitably going to be wrong about which part is actually slow until that point so your optimisation hours budget will be better spent with a profile in hand. There's a parallel here to "no, you did not find a bug in the compiler". Yes, ok, once every five years or so I actually did find a bug in the compiler, but assuming you aren't that smart is still a far far better default approach.
      - ricardobeat 5y ago
        That's a straw man argument - I did not say it's concern #1, just pointing out that React forces that specific trade-off. Balancing complexity, maintainability, AND performance is really hard with hooks, the lack of built-in reactivity and inefficient baseline behaviour. It's rarely a matter of "just combine it into one reducer". On top of that, profiling and optimizing a real world application with a dozen hooks in every component is pretty painful.
- progrus 5y ago
  “Long lists of generic hooks” is a symptom of devs not having climbed the difficulty curve a bit further, to where they are writing custom hooks, and using fewer in each component, IMO. It’s understandable to stumble into this difficulty though, and a bit of deceptive marketing on the part of the hooks folks. They should be upfront that using hooks well in a real app requires a lot of careful thinking of the kind that many “typical” programmers do not have much practice in, and then the maintenance of whatever code comes from the effort. The functional-programming-mindshare situation seems to be improving slowly, but still.
- Scarblac 5y ago
  When you have multiple hooks in a component it usually makes sense to put them in a function with a good name - a custom hook. It's easy and almost always usually gives simple code.
  - dnsco 5y ago
    a benefit of custom hooks is that you can test complex state logic isolated from the view
  - bryanrasmussen 5y ago
    sure, and sometimes it still would be simpler with the older lifecycle methods. Not saying it is always the case but for some reason it is assumed it could never be the case.
- onion2k 5y ago
  hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code) If the lifecycle methods you're referring to are things like componentWillReceiveProps or getDerivedStateFromProps then the React blog covers why they were problematic https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d.... It was very common for developers to make things that would repeatedly rerender when other parts of their app updated. Hooks make that far less likely to happen. That said, I agree that a getDerivedStateFromProps method is more readable and much clearer than useEffect(()=>{ // stuff }, [big, list, of, props]);
  - bryanrasmussen 5y ago
    that a particular way of doing things was problematic for the community as a whole when measured across all usages does not invalidate the observation that there were some usages in which that particular way seemed better. when, as I often encounter, organizations mandate all hooks all the time they are not throwing the baby out with the bathwater, but they are maybe throwing out the baby's rubber duckie without considering that might be useful to have around at times.

bryanrasmussen 5y ago

In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing number of hooks to make everything hang together.

seer 5y ago
Maybe, but in my experience whenever I encounter an incomprehensible mess of hooks it usually ends up because devs were not using all the tools that react provides. For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer. Components that don’t benefit much from splitting up could have their business logic wrapped into a context, and let the view code be just jsx without all the interweaving of code and templates. Maybe the one benefit of classes was like it forced you to think in business logic, then render. React still has that, you just need to dive a bit deeper into its toolbox. The result usually turns out much more flexible - contexts neatly wrap business logic for all of its descendants, classes don’t. I think this was maybe because react actually allows you to write messy code, and it’s still performant and works. But in the end it just kinda postpones the inevitable maintenance burden. I guess solid.js from the looks of it might postpone it a bit more. I just worry that solid looks more like magic, and some invariant somewhere will just break and I wouldn’t know what sequence of reactions actually led to that infinite loop that crashed the page. Haven’t tried it myself though, might more understandable in the end…
- ricardobeat 5y ago
  > For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer You've just deoptimized your app, and your whole component will re-render on every change. > Components that don’t benefit much from splitting up could have their business logic wrapped into a context You did it again. More unnecessary re-renders. > it’s still performant and works True that 'it works', but it's usually not as performant as you think - we just have really fast computers and phones now.
  - littlecranky67 5y ago
    Why is performance always argument No. 1? The true rule is, code must be readable and maintainable first. THEN, if there are performance issue with the code (no theoretical ones, you HAVE to have a real-world profiling report of YOUR code in your hands when you argue about performance), you can refactor for performance.
    - mst 5y ago
      A thing I remind myself of regularly: Avoiding worrying about optimisation up front too much is not avoiding caring about optimisation at all, it's reserving the number of hours you can expend on optimisation until you have enough working to have a profile available, because you are inevitably going to be wrong about which part is actually slow until that point so your optimisation hours budget will be better spent with a profile in hand. There's a parallel here to "no, you did not find a bug in the compiler". Yes, ok, once every five years or so I actually did find a bug in the compiler, but assuming you aren't that smart is still a far far better default approach.
    - ricardobeat 5y ago
      That's a straw man argument - I did not say it's concern #1, just pointing out that React forces that specific trade-off. Balancing complexity, maintainability, AND performance is really hard with hooks, the lack of built-in reactivity and inefficient baseline behaviour. It's rarely a matter of "just combine it into one reducer". On top of that, profiling and optimizing a real world application with a dozen hooks in every component is pretty painful.
progrus 5y ago
“Long lists of generic hooks” is a symptom of devs not having climbed the difficulty curve a bit further, to where they are writing custom hooks, and using fewer in each component, IMO. It’s understandable to stumble into this difficulty though, and a bit of deceptive marketing on the part of the hooks folks. They should be upfront that using hooks well in a real app requires a lot of careful thinking of the kind that many “typical” programmers do not have much practice in, and then the maintenance of whatever code comes from the effort. The functional-programming-mindshare situation seems to be improving slowly, but still.
Scarblac 5y ago
When you have multiple hooks in a component it usually makes sense to put them in a function with a good name - a custom hook. It's easy and almost always usually gives simple code.
- dnsco 5y ago
  a benefit of custom hooks is that you can test complex state logic isolated from the view
- bryanrasmussen 5y ago
  sure, and sometimes it still would be simpler with the older lifecycle methods. Not saying it is always the case but for some reason it is assumed it could never be the case.
onion2k 5y ago
hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code) If the lifecycle methods you're referring to are things like componentWillReceiveProps or getDerivedStateFromProps then the React blog covers why they were problematic https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d.... It was very common for developers to make things that would repeatedly rerender when other parts of their app updated. Hooks make that far less likely to happen. That said, I agree that a getDerivedStateFromProps method is more readable and much clearer than useEffect(()=>{ // stuff }, [big, list, of, props]);
- bryanrasmussen 5y ago
  that a particular way of doing things was problematic for the community as a whole when measured across all usages does not invalidate the observation that there were some usages in which that particular way seemed better. when, as I often encounter, organizations mandate all hooks all the time they are not throwing the baby out with the bathwater, but they are maybe throwing out the baby's rubber duckie without considering that might be useful to have around at times.