3 ms·

I've become a big believer in separately managed state. Even if something would convince me to move away from Redux I would still stick to the pattern of dividi

by ng12 9y ago

I've become a big believer in separately managed state. Even if something would convince me to move away from Redux I would still stick to the pattern of dividing code into three stacks: data/state management, components, and stateful glue code (AKA reducers, components, and containers in the React universe). Redux is most useful in that it keeps you honest to this paradigm and that it provides some nice dev tools -- the library itself doesn't really matter. I don't think there's anything wrong with a global event bus in theory but in practice it often lends itself to abuse. In fact, I'm currently moving a legacy application to React/Redux and found that the global event buses were a good idea in theory, a spaghetti factory in practice.

Matthias247 9y ago
I also think seperating state from the view components is a great idea. But I don't see that a Redux-like approach is needed for that. What I deployed successfully in a larger app was just some normal kind of MVVM architecture: I implemented service components (in form of Typescript/ES6 classes) which store the state they care about and expose getters for the current state and mutating functions for changing the state. These are basically the M(model) parts of MVVM. The view components (Angular2 viewmodels as well as React components) get the services injected and use the latest data from the services in order to render it into the view (oneway data binding). If realtime updates from the service to the view are required then the services can expose their state as Observables, to which the ViewModels can subscribe. I like the approach, because it allows the data-consumers (view-components) to see the sources (models / services) just as a domain specific strongly typed interface, which allows to change the state and retrieve it with normal object-oriented patterns. Dispatching some non-strongly typed action into an eventbus and hoping that anybody will care about it seems less type-safe approach to me.
PettyAdm 9y ago
Have you considered something like Cycle JS (https://cycle.js.org/ https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.

by ng12 9y ago

Matthias247 9y ago

I also think seperating state from the view components is a great idea. But I don't see that a Redux-like approach is needed for that. What I deployed successfully in a larger app was just some normal kind of MVVM architecture: I implemented service components (in form of Typescript/ES6 classes) which store the state they care about and expose getters for the current state and mutating functions for changing the state. These are basically the M(model) parts of MVVM. The view components (Angular2 viewmodels as well as React components) get the services injected and use the latest data from the services in order to render it into the view (oneway data binding). If realtime updates from the service to the view are required then the services can expose their state as Observables, to which the ViewModels can subscribe. I like the approach, because it allows the data-consumers (view-components) to see the sources (models / services) just as a domain specific strongly typed interface, which allows to change the state and retrieve it with normal object-oriented patterns. Dispatching some non-strongly typed action into an eventbus and hoping that anybody will care about it seems less type-safe approach to me.

PettyAdm 9y ago

Have you considered something like Cycle JS (https://cycle.js.org/ https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.