How UI-driven state increases accidental complexity

Re:How UI-driven state increases accidental complexity by YuukiRey on Wednesday March 25, 2020 @08:42AM (#22683962)

I wish there was more experimentation in the front end landscape. Right now every major framework mixes state, logic and view. It doesn't matter if your state and logic is extracted into hooks, at the end of the day you're still mixing things by importing modules that directly add state and logic to components. I'd love to see a non-trivial app written __without using a single useXXX or class component__. The only thing your view layer is allowed to do is dispatch an action, or call an effect, which is interpreted outside that view layer. Of course this raises all sorts of questions, such as what about 100 instances of the same dropdown component which now all need to store their state somewhere. But I'd still like to see what working with that would feel like. I think The Elm Architecture would be pretty close to that (or exactly that, I don't know).

(I'm not saying the above would be better than what we have, just that it seems like it should be properly explored)

[ Parent | on HN ]

Re:How UI-driven state increases accidental complexity by sbergot on Wednesday March 25, 2020 @09:06AM (#22684115)

I mean... have you heard about redux? This is pretty much what you are describing. If you are looking for UI experimentation js framework are a good resource ;-)

I have used redux in a medium sized app.

The advantage is that there are lots of documentation. Developper can lean on those resources and the result is an architecture that is shared easily among multiple teams.

The disadvantage is that handling asynchronous effects is unclear. Also sometimes adding a flag to manage some subcomponent state require a lot of work. It also clutters your centralized state. It can also be a pain to manage forms this way. And by that I mean managing the state of a form that is in the process of being filled.

Currently my favorite way of designing js apps is a mixed approach. Put all your business code in model classes. Only centralize the state that is important to your application. Sprinkle local states when appropriate. Use hooks & context to inject your model classes in the right components.

[ Parent | on HN ]

Re:How UI-driven state increases accidental complexity by YuukiRey on Wednesday March 25, 2020 @09:19AM (#22684229)

Haha I should have mentioned this probably but yes I use redux a lot. The thing is that I suspect that the vast majority of people mix and match redux and local state. And what I have in mind is a strict, 100%, no exceptions separation. Just for experimentation purposes.

> The disadvantage is that handling asynchronous effects is unclear.

To be honest to me this is one of the areas where redux really shines. I've had great success with both redux-saga and redux-observable

[ Parent | on HN ]