5 ms·

I too can't shake the feeling that hooks are off. I like JSX and the component model. In React and like-minded projects, I look at a stack trace and see that i

by wbercx 6y ago

I too can't shake the feeling that hooks are off. I like JSX and the component model. In React and like-minded projects, I look at a stack trace and see that it starts at some kind of batch renderer. I can't tell "why", "how" or sometimes even "what" broke. The input part of it is completely lost. I work on a Backbone application where stack traces are much more obvious. They usually tell you the whole story. I find that juniors who were mostly exposed to React have a tendency to completely ignore stack traces, and am now wondering if they are just conditioned to them being unhelpful.

unityByFreedom 6y ago
> I too can't shake the feeling that hooks are off. Well the alternative to hooks is componentDidMount, componentDidUpdate, etc. It's a lot easier to sync state and UI when the logic for doing so can be put in one place.
- ricksharp 6y ago
  I’ve been using hooks for a year, and they are awesome (once you get used to it). I can write the same component in 1/3 of the code in a functional style. The debugging story isn’t great if you expect to be able to use breakpoints. It’s all about putting console.log wherever really. The beauty comes in the speed of coding, I can move so fast that I always build a mock version of my api layer and can have the entire UI done rapidly.
  - gaoshan 6y ago
    You can throw in debugging statements (`debugger;`) when some hook doesn't seem to be hitting a breakpoint. Stops things just fine.
acemarke 6y ago
I worked on a Backbone app for several years (and still do, technically - we're about to do a final push to finish migrating it to React). I also liked the fact that you could step into Backbone code, and back out to app code on the other side. Backbone's source is small, and you can see exactly what it's doing. However... React is simply a fundamentally superior programming model, for a wide variety of reasons. I can treat React as a black box, knowing that if there's a problem in my UI, it's because of either the logic in my components, or the data those components are using for display. (Then there's things like being able to arbitrarily compose child components together and pass them props, vs randomly trying to attach subviews or something via umpteen different plugins.) I'll agree that seeing a stack trace with React library code isn't typically helpful. But, the error messages are usually sufficient to tell me what kind of an issue is going on, and point me to the right component or part of the tree to start debugging the real issue. Somewhat related to this, I put together an extensive post earlier this year called "A (Mostly) Complete Guide to React Rendering Behavior" [0] that digs into detail on how React's rendering actually works, as I've found that a lot of people seemed to be missing how some of the pieces of rendering fit together: [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
- scns 6y ago
  Even though i don't do front end anymore, thank you for your tireless work and detailed comments on HN, making the ecosystem better.
  - acemarke 6y ago
    Thank you, and you're welcome! Nice to know someone appreciates the time I waste on social media :)
    - scns 6y ago
      s/waste/invest in/g ftfy
csande17 6y ago
One thing that feels off about hooks to me is the "primitive" ones React provides. Like, here are the basic things that hooks can do: 1. Tell the component to re-render 2. Store an object that persists between component renders 3. Run something after the component has been rendered 4. Run something when the component unmounts React doesn't give you functions that do these operations individually. Instead, you get weird hybrids like useState, which combines storing a value with telling the component to rerender when the value changes. So you sometimes have to jump through hoops to get the behavior you want. (Well, useRef sort of does (2), except it constructs the object itself.)
- the_other 6y ago
  I don’t understand this complaint. Components are functions of their props and state, returning markup (in the form of a descriptor foe the rendering engine). When a prop or piece of state changes, the component must re-render. The fact that useState might be responsible isn’t relevant. That said, I’m also still struggling with hooks (and I like functional programming in JS). I want to like that hooks let you wrap your domain logic into neat bundles, but I find that I miss the lifecycle callbacks of the older class based style. Hooks based components are trying to make modules that are “about” the problem domain they illustrate, but they do it as a feature of React. React isn’t about your problem domain, it’s about driving the DOM and rendering, and I think it makes more sense to treat React code that way. I’m open to having my mind changed on this. I have spent way more time writing classical React than hooks-based.
  - nicoburns 6y ago
    > but I find that I miss the lifecycle callbacks of the older class based style. Why not continue to use the class based style? It's still supported. We're using hooks for some simpler cases where they really cut down on boilerplate, but we're continuing to use classes for more complex cases where we find it more readable.
    - the_other 6y ago
      That's what I did at my last gig, where I owned the codebase. At my current gig, I share it with 10 people and the decision to move to hooks was made before I joined.
Cthulhu_ 6y ago
+1 with the stack traces; I long for simple and straightforward, no magic applications. The front-end ecosystem seems to move to the opposite; multi-stage compilation / transpilation steps even in development mode, with tooling to make it manageable and debuggable (source maps). The development mode of my current application needs to reload 35MB worth of stuff at every refresh. (should look into whether I can optimize that, idk).

by wbercx 6y ago

unityByFreedom 6y ago

> I too can't shake the feeling that hooks are off. Well the alternative to hooks is componentDidMount, componentDidUpdate, etc. It's a lot easier to sync state and UI when the logic for doing so can be put in one place.

ricksharp 6y ago
I’ve been using hooks for a year, and they are awesome (once you get used to it). I can write the same component in 1/3 of the code in a functional style. The debugging story isn’t great if you expect to be able to use breakpoints. It’s all about putting console.log wherever really. The beauty comes in the speed of coding, I can move so fast that I always build a mock version of my api layer and can have the entire UI done rapidly.
- gaoshan 6y ago
  You can throw in debugging statements (`debugger;`) when some hook doesn't seem to be hitting a breakpoint. Stops things just fine.

acemarke 6y ago

I worked on a Backbone app for several years (and still do, technically - we're about to do a final push to finish migrating it to React). I also liked the fact that you could step into Backbone code, and back out to app code on the other side. Backbone's source is small, and you can see exactly what it's doing. However... React is simply a fundamentally superior programming model, for a wide variety of reasons. I can treat React as a black box, knowing that if there's a problem in my UI, it's because of either the logic in my components, or the data those components are using for display. (Then there's things like being able to arbitrarily compose child components together and pass them props, vs randomly trying to attach subviews or something via umpteen different plugins.) I'll agree that seeing a stack trace with React library code isn't typically helpful. But, the error messages are usually sufficient to tell me what kind of an issue is going on, and point me to the right component or part of the tree to start debugging the real issue. Somewhat related to this, I put together an extensive post earlier this year called "A (Mostly) Complete Guide to React Rendering Behavior" [0] that digs into detail on how React's rendering actually works, as I've found that a lot of people seemed to be missing how some of the pieces of rendering fit together: [0] https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/ https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...

scns 6y ago
Even though i don't do front end anymore, thank you for your tireless work and detailed comments on HN, making the ecosystem better.
- acemarke 6y ago
  Thank you, and you're welcome! Nice to know someone appreciates the time I waste on social media :)
  - scns 6y ago
    s/waste/invest in/g ftfy

csande17 6y ago

One thing that feels off about hooks to me is the "primitive" ones React provides. Like, here are the basic things that hooks can do: 1. Tell the component to re-render 2. Store an object that persists between component renders 3. Run something after the component has been rendered 4. Run something when the component unmounts React doesn't give you functions that do these operations individually. Instead, you get weird hybrids like useState, which combines storing a value with telling the component to rerender when the value changes. So you sometimes have to jump through hoops to get the behavior you want. (Well, useRef sort of does (2), except it constructs the object itself.)

the_other 6y ago
I don’t understand this complaint. Components are functions of their props and state, returning markup (in the form of a descriptor foe the rendering engine). When a prop or piece of state changes, the component must re-render. The fact that useState might be responsible isn’t relevant. That said, I’m also still struggling with hooks (and I like functional programming in JS). I want to like that hooks let you wrap your domain logic into neat bundles, but I find that I miss the lifecycle callbacks of the older class based style. Hooks based components are trying to make modules that are “about” the problem domain they illustrate, but they do it as a feature of React. React isn’t about your problem domain, it’s about driving the DOM and rendering, and I think it makes more sense to treat React code that way. I’m open to having my mind changed on this. I have spent way more time writing classical React than hooks-based.
- nicoburns 6y ago
  > but I find that I miss the lifecycle callbacks of the older class based style. Why not continue to use the class based style? It's still supported. We're using hooks for some simpler cases where they really cut down on boilerplate, but we're continuing to use classes for more complex cases where we find it more readable.
  - the_other 6y ago
    That's what I did at my last gig, where I owned the codebase. At my current gig, I share it with 10 people and the decision to move to hooks was made before I joined.

Cthulhu_ 6y ago

+1 with the stack traces; I long for simple and straightforward, no magic applications. The front-end ecosystem seems to move to the opposite; multi-stage compilation / transpilation steps even in development mode, with tooling to make it manageable and debuggable (source maps). The development mode of my current application needs to reload 35MB worth of stuff at every refresh. (should look into whether I can optimize that, idk).