3 ms·
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
by mvdtnz 2y ago
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.
- paulddraper 2y agoHooks are the best thing for frontend dev since async/await.
- recursive 2y agoI would believe that if there were exactly two things in front end.
- LunaSea 2y agoI 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 2y agoThat’s true of every other GUI tech. Angular too many digest cycles anyone?
- taeric 2y agoI 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 2y agoSomething 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 2y agoI 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 2y agoTry 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 2y agoThat 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 https://github.com/Facepunch/react-class-model (note: context is not required)
- eddythompson80 2y agoTo 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 2y agoI'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.