The vast majority of state problems in React are a result of nonsense cargo culting around the idea that classes are somehow bad.
IMO it's the central tenet to the dogma that "state must not be mutable".
In React {Transitions} = F(state)
11–20 of 55 posts
Re: In React {Transitions} = F(state)
#12Every 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.
Hooks are the best thing for frontend dev since async/await.
I would believe that if there were exactly two things in front end.
Re: In React {Transitions} = F(state)
#13I might just not be aware of a better alternative for React hooks, but I don't like useEffect. I feel like it makes it much more difficult to manage state and transitions compared to SolidJS or other frameworks that use signals.
There’s no denying that the idiomatic solution is sometimes far from obvious, but idiomatic react wants useEffect to only about synchronizing react with external systems. Everyone reaches for it to synchronize between components and do all sorts of other non-idiomatic things though, and that’s where the pain comes in.
Re: In React {Transitions} = F(state)
#14The most direct way of solving the immediate problem is to make transitions idempotent. Why must it be an error to complete an already complete TODO? Completing an already complete TODO should be a no-op. That simplifies things greatly.
Of course many actions logically cannot be made idempotent, but for the subset that can, do it as much as possible.
Re: In React {Transitions} = F(state)
#15Re: In React {Transitions} = F(state)
#16> A React application can be thought of as modeling a state machine. Each render takes a state and produces the UI for that state. This is the famous UI = f(state) mental model of React. But, for complex applications, formally enumerating a transition table is often not feasible. When the number of possible states is not finite, a table will not suffice and we must instead define a mapping: a conceptual function whic…
> But, if your problem is simple enough that you can represent it with a handful of states with two or three transitions each, then you have a very trivial problem, so trivial that the state-machine diagram likely added nothing at all to your understanding of it.
And yet, it's extremely common to see apps with clearly broken states and state transitions for what should be relatively "trivial" state machines. Think play/pause buttons, buttons with loading states, form fields with error states, etc.
Re: In React {Transitions} = F(state)
#17The vast majority of state problems in React are a result of nonsense cargo culting around the idea that classes are somehow bad.
I'm glad I learned React during the time when React.createClass was the only way. It was simple and intuitive. At that time the docs included a very lengthy discussion of what should be put inside the class and what should be passed via props. It was very helpful when it comes to teaching newcomers to architect their app. It also carried over the years of intuition by the typical dev working with OOP. Much better than the current trend of using hooks for everything.
Re: In React {Transitions} = F(state)
#18"This is the famous UI = f(state) mental model of React". Famously incorrect generalization. Why? For example, the useRef hook enables components to hold their own state. React components are not guaranteed to be pure functions. Of course, it can depend on how one writes their code, but it's not a guaranteed that UI = f(state) in React in general.
Re: In React {Transitions} = F(state)
#19Every 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.
Hooks are the best thing for frontend dev since async/await.
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.
Re: In React {Transitions} = F(state)
#20The #1 reason I push for SSR/vanilla web is to consolidate all state to the server. Literally the only thing on the client could be a session cookie. A few hundred bits of entropy. That's the client's state. Imagine how simple that would be.
The cost of a round trip for every UI interaction might seem high, but I've never seen a distributed client/server state machine model that could compensate for any of these alleged UX harms without simultaneously bringing in more complexity than anyone was prepared to deal with.