Hacker News Reader

Comment by superice | Hacker News Reader

This seems awfully similar to the Elm model of managing state. Perhaps it's me being unenlightened, but I never understood why all state in an application needs to be managed centrally. Take a select box for example, its open-state is not something I think a central store should necessarily know about right?

I always find that if I want to write an app in the Elm style (or with Redux), I have to traverse up the tree every time I am working on a leaf node. Each input field in a form should not necessarily cause me to have to rework everything up to the root node right? Am I doing it wrong, or am I just missing what benefits this approach brings to offset this extra development cost?

View on HN

I'm not a fan of the "global state as a default" approach. There are definitely advantages. It is easy to reason about and to test, and is attractive from a purist point of view, but its usage can definitely add redundancy and complexity to the code with current tools.

Especially for server-centric CRUD apps with forms and lists, this is often abused. If you're reloading lists when navigating to them, and fetching form data when updating a record, then you don't really need global state. If you want to cache, perhaps a plain cache is enough.

If you need some piece of data to affect multiple components in different parts of the hierarchy, sure, make it global, but if you can get away with mostly local state the codebase will be simplified. IMO.

I don’t find global central state easier to reason about. It’s inherently more complex managing the state of a component far away from it in some other place. But I think it’s often worth doing because it enables you to make better UIs. There are many situations where, with two seemingly unrelated components, it actually is better if there is a subtle connection between them - eg. this menu should auto-close if the user started interacting with another component except during some specific other state). Such cases are often not obvious until you are playing with a prototype, they can’t be planned for. And these cases are common, if you are going for a really good UI. Having each component locally manage their state makes it unreasonably complex and nasty to add such couplings.

I 100% disagree. If there's need for centralized state for certain pieces of data, make it so. But premature usage of global state under the guise of "I might need it in the future" is a plague that makes apps much more complex than they have to be.

There's zero need to make everything be the same. There's not even the need to keep state in one single place: you can control all the state and its transitions locally but then "copy" to state management if you need it somewhere else. This is a perfectly valid solution too.

Another problem of using global state for everything is that it reduces the possibility of using a lot of component-level or hook-level abstractions that would be otherwise very useful. You're now forced to do everything through Redux or something like that.

There's no need to rush for an "absolute" solution with all that overhead as if it was a golden bullet. It's not.

Having it globally makes serialisation of the state possible and it can be useful for testing. having no hard line between global and local state can speed up development.

the issue is that current frameworks make global state awkward to pass around. if this were fixed then global has all of the advantages.

Some state (generally, the stuff you would want to persist) should be global. Some state (e.g. widget animation or your select-box example) should be local.

I agree that this project misses the mark.

> I always find that if I want to write an app in the Elm style (or with Redux), I have to traverse up the tree every time I am working on a leaf node. Each input field in a form should not necessarily cause me to have to rework everything up to the root node right? Am I doing it wrong, or am I just missing what benefits this approach brings to offset this extra development cost?

In Elm specifically, you should not have state in the form elements. They should only have component-specific update functions like "Checked" / "Unchecked" that are mapped to form level messages and of course the view function.

You can have both local and global state. That checkbox sounds like it should be handled locally. However, if it's part of a bigger scope (e.g. a form) I would still put the state somewhere central, like in a form context or even in the global store. It's not unthinkable that another part of the form may affect or want to read the checkbox state in the future. You would probably also want to bootstrap the form with previous data when editing, which becomes trivial if it just listens to a big state tree representing the form instead of manually passing default props to the component.

And no, you don't need to to prop drilling when using contexts or a state manager.

One of the parts that I loved at the beginning of my React journey was the component'ization -- the eschewing of "model-view-controller", because really? is that always the best cut-line? How about I do the unix model of a component -- do 1 thing and do it really well as in your select box example.

Anyways, the tide turned again and everyone said, "functional programming is the bees knees! [don't mind these strange hooks that inject side-effects and state]". Then they said, why are we storing state in these pure functional entities. Let's separate out the state and the control..

Back to model-view-controller. Yay?

I think this entire thread has gone of the rails with the local/global discussion. You can have your entire state captured as one 'entity' without every control inside the state being global. The controls can be in isolation, and has nothing to do with the 'state' of the entire page as a whole. Or can break it down into substates if desired, but it doesn't mean each component is global to make that happen.

You are doing it wrong yes.

The root node can intercept all messages but its main responsibility (TEA) is to dispatch the messages to the right component(s).

Sure, that makes sense in a Redux app where you can use FP techniques as you see fit. How do you do that in something strictly functional like Elm? As I understand it 'local state' or a component handling messages locally is not really a thing there.

I am using elmish, which I think is similar enough: every component has its own update method and events it dispatches.The events get wrapped in every parent component until it gets to the root, there it gets unwrapped and passed to the appropiate child update method. At any point, you can intercept the event/update.

(Each component consists of a view, a model and an update function, the model contains wrapped versions of the children models and dispatched updates get passed into the children updates)

What is the role of the "root node" in Elm?

It's the broadest level at which two elements can affect each other.

Classic example: if you have a notification bubble near the top of the page, and a notification gets created by some component hidden deep inside the app structure, that message can't be handled in a local sub-model; it must travel all the way to the root node to update the notification bubble stack in the main model.

(Which is why nowadays I prefer to skip the nesting and just have a flat list of all messages in the app. With good spacing and naming, it's quite maintainable and just as solid.)

Just imagine your root function as:

F(f_1(x_1), f_2(x_2), …, f_n(x_n))

The root function is a collection of projections acting on (x_1, x_2, …).

And the components receive the right set of coordinates to act on.

I’m not sure if it’s clearer that way though.

You are absolutely right. Almost none of your data needs to be global and if it is, you're doing it wrong.

Reply on news.ycombinator.com