[wbercx]

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.

[acemarke]

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-...

[scns]

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]

Thank you, and you're welcome! Nice to know someone appreciates the time I waste on social media :)

[scns]

s/waste/invest in/g

ftfy

[csande17]

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]

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.

[WorldMaker]

> 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.

This is why I think it's going to take a bit more time with hooks code to realize the opposite to csande17's complaint is really true: the problem with the hooks React ships with is not that they aren't primitive enough (as the sibling comment points out, csande17 probably is also missing that some of the primitives they are looking for expressly don't exist as React hooks because they don't fit the algebraic effect model React is moving toward, versus the lifecycle model React is moving away from), but instead that the hooks React ships with are still (or least feel) far too primitive an algebra for the "calculus" needed for at least some problem domains (if not most problem domains).

I don't specifically have any answers for what the next layers up will be, though I appreciate this article for trying to explain how algebraic effects work in other languages because that provides ideas from other places of how their primitives get composed.

[nicoburns]

> 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]

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.

[Vinnl]

I don't think hooks can actually do 1, 3 and 4. Components re-render whenever React feels like it's a good moment to do so. That happens to include "when state changes", but you're not able to rely on that. This will supposedly become more apparent once Concurrent Mode finally lands.

(You can certainly fault React for it being hard to grok the "correct" mental model, but it makes sense that its primitives do not match the wrong mental model to me.)

[unityByFreedom]

> 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]

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]

You can throw in debugging statements (`debugger;`) when some hook doesn't seem to be hitting a breakpoint. Stops things just fine.

[Cthulhu_]

+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).