Comment by wildrhythms | Hacker News Reader

Comment by wildrhythms | Hacker News Reader

Parent Full thread

I can sympathize with this, and I personally love React. It's very easy for components to start diverging from "the" state (some global state) by holding their own internal state (useState).

I encounter this in situations like: I want to open a drawer when an input is focused; the global state doesn't need to know about every input with a drawer, so useState on the component is useful. Already I've diverged from a global state. And I want something else to happen when the drawer opens (maybe an async network fetch, loading indicator, error messaging if the network fetch fails...), so I add useEffect, and now I'm adding side effects into the mix, and it becomes very difficult to reason about how the component got into its current configuration at any given time.

At work I have these components that I imagine will start small, that tie into some global state, but end up needing to keep their own internal state that grows and grows, and I have useEffects all over the place watching for other results of side effects... it's a gigantic mess. I don't know what the solution is. UIs are hard

I can relate to this.

> the global state doesn't need to know about every input with a drawer

I like this example because it is exactly how it happens in real life every single time in my experience.

It does not need it, purely an aesthetic reason. Maybe it will perform worse if it does (maybe). If we commit to the model that we represent everything in global state (singleton) this problem disappears.

Let's say we keep some state for that drawer and pass it to the global state. Then we would keep a global state that is always current and an ELM-like model that is easy to understand (https://guide.elm-lang.org/architecture/)

For some reason that commitment is the first thing to drop, and usually not even for practical reasons, but for aesthetic ones or hypotheticals.

It seems to me it is this permanent fight between flexibility and correctness. If we want correctness we should stick IMO to a simple model (let's say ELM architecture, for example) and ruthlessly apply it, no exceptions.

If we want to use context, redux, local state, mobx, some direct DOM manipulation (as I see sometimes) then it is no wonder we cannot prove its correctness.

Most people find it difficult to accept constraints, even for their own good (type annotations, even using git). I still remember a project where I introduced git and after a few months of leaving an ex-colleague (still in touch) proudly announced that they got rid of it because it was slowing the team down.

"All of humanity's problems stem from man's inability to sit quietly in a room alone" — Pascal

Exactly! I don't know the right solution, either. All the tutorials I've read don't seem to know, either. They're either too simple to where that doesn't become an issue, or they do what you do, and it looks like a mess to me.

In Vue, I'll usually create a service to handle local-yet-shared state (which is just Vanilla JS, no Vue constructs), or create a VueX module (which you could use in React, as well). It's much easier to follow than React's wrapper methods.

In my experience, in both React and Angular, a lot of the things I expect a framework to handle need to be managed by the developer (namely, keeping shared values in sync). Over time, patterns can deviate to where different components/modules use different patterns, and devs spend extra time reading through component files to figure out why their feature isn't updating as expected.

Reply on news.ycombinator.com