[mvdtnz]

Every time I delve into a large React codebases (and I have worked on some real monsters) I have a laugh to myself at how badly these guys tie themselves up in knots in order to preserve the supposed simplicity of the state -> UI function. When you invent something as insane as the hooks API in order to maintain purity it's time to step back and consider if you're really on the right track.

[taeric]

I want to disagree with you, but I just can't. Every simple example on the different ideas for managing state in React is easy and seems reasonable. Every application I encounter seems to quickly take that and just start laughing at me.

[CharlieDigital]

Something with React's approach is fundamentally broken, IMO, and this is why we see so many variations of state management libraries on React that we don't see on other frameworks because state kind of "just works" and is really, really simple when you are using signals.

My sense is that in React, the complexity comes from the management of minimizing the "blast radius" of state changes to prevent over-renders. So there are a lot of different approaches and ways that folks have cleverly engineered to solve this problem, but none of them feel as simple as say Pinia on Vue, for example.

[Rohansi]

I think state management is the worst part of using React. All of the popular/highly recommended packages to manage state require you to write code in unconventional ways without really explaining the design decisions. Why use reducers? They're basically different (worse) syntax for mutable object method calls.

[hombre_fatal]

Try MobX. I think it's the holy grail of state management.

You have your app state in an object/class, and components automatically rerender when the part of the store changes that they access during render.

    class Store {
      counter = 0
      constructor() { makeAutoObservable(this) }
      increment() { this.counter++ }
    }

    const Component = observer(() {
     const store = useStore()
     const click = () => store.increment())
     return <button onClick={click}>{store.counter}</button>
    })

It has a very light set of idiosyncrasies for what it gives you unlike, say, redux.

[Rohansi]

That looks pretty good! I actually implemented my own state management that works like that five years ago because I didn't like the options at the time.

https://github.com/Facepunch/react-class-model (note: context is not required)

[eddythompson80]

To me, the state -> UI paradigm isn't simple in the sense "oh, that was one click, simple". It's simple in the sense "anyone can do it if you just understand/follow these 10-15 simple rules". Once you know these simple rules, you can jump straight into 95% of react projects and be productive fairly quickly.

[blurker]

I've seen some pretty good React codebases and I've seen plenty of backend spaghetti code. In all cases it's not the tools, it's the programmers and usually it's layers and layers of people not taking the time to write clean code. Probably because their management doesn't value it or they don't have someone with the experience necessary to guide them towards clean code.

[paulddraper]

Hooks are the best thing for frontend dev since async/await.

[LunaSea]

I can't count how many issues I've seen due to: missing useEffect dependencies, cyclical hooks, unnecessary rerenders, etc. linked to this API.

It has a lot of expressivity but is incredibly brittle and dangerous.

[paulddraper]

That’s true of every other GUI tech.

Angular too many digest cycles anyone?

[recursive]

I would believe that if there were exactly two things in front end.