Some context: i came from a Delphi (Windows desktop) development background but, in the last years, i invested in web development. Initially in Backbone/Marionette which have worked well for personal projects and auxiliary apps.
We have a project to migrate our medium to large sized, commercial, desktop application. Since involves third party investment with roadmap, deadlines we need a not niche tech stack which contracted programmers can work on without much training.
So i needed a mainstream state management to work with web components (this choice is another history). It does not have many. Backbone has lost mind share, although i can ensure it can do The Job Done. Ember and Ember Data is all or nothing. Angular also lives in its own world. This leaves the React friendly state managements.
I looked into Redux which is by far the most used, with its merits, and easier to have devs to know how to work with it. I really tried to switch my mind to use redux but every time something made me step back from it. Sometimes the boilerplate, sometimes the need to everything (like routing) be managed by redux, sometimes the number of choices to be made...
Mobx is another alternative which sounds less intimidating. So i used this conversion to test how would work in practice. So far has met the demands of allowing to create modern (Reactive) UI with a manageable testable state.
BTW somethings in the RealWorld architecture, inherited by React version, i would do differently like decoupling the state update from the components.
Thanks for the reply. We're also looking into MobX as a solution in comparison with Redux which we find from experience leads to too much boilerplate.
So far I'm intrigued by MobX and based on my initial efforts to integrate into some of our components, I find it quite straightforward to use.
I am a little bit concerned about the 'magic' it is doing compared to Redux which is much more straightforward. But maybe I just need to dig under the covers of MobX a little.
I'm interested if you could clarify what you mean by your last comment:
... I would do differently like decoupling the state update from the components
In general, my experience with building React/web components using state management solutions like Redux/MobX is that they lead you to create components/state that are unfortunately tightly coupled to a specific application scenario and hence are not as easily reusable by different applications.
We work on a large web application that can be thought of as being comprised of many smaller applications/pages and we want our components to be re-usable across many of those smaller applications. So I'm focusing on how we can use something like MobX to allow state to be managed by components without making too many assumptions about how the components might be used together. But it's not sufficient to just keep state in each component as there are scenarios where we do what state to be shared if the components are used on the same page/application part.
connectedCallback(){super.connectedCallback()// this could be removed}shouldUpdate(changedProperties){// probably also not necessary here since route change could be handled elsewhere if(changedProperties.has('username')){this.trigger('username:change',this.username)}if(changedProperties.has('pathname')){this.trigger('pathname:change',this.pathname)}returntrue}
The responsibility to call e.g. articlesStore.loadArticles() should be in a layer above what many call the orchestrator layer. I like having the route as this layer (not component based) but can be separated classes.
With this architecture is easier to test the component (just ensure calls the events when appropriate).
This is the core principle of data down, events up pattern
Other things to improve decoupling: move the stores to a instance property instead of a context property and listen to route changes elsewhere
The architecture of the demo is contaminated by React thinking that everything is handled in a component (routing, data loading etc) one of the things why i don't like React.
You can look what i mean by using route like the orchestrator here
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some context: i came from a Delphi (Windows desktop) development background but, in the last years, i invested in web development. Initially in Backbone/Marionette which have worked well for personal projects and auxiliary apps.
We have a project to migrate our medium to large sized, commercial, desktop application. Since involves third party investment with roadmap, deadlines we need a not niche tech stack which contracted programmers can work on without much training.
So i needed a mainstream state management to work with web components (this choice is another history). It does not have many. Backbone has lost mind share, although i can ensure it can do The Job Done. Ember and Ember Data is all or nothing. Angular also lives in its own world. This leaves the React friendly state managements.
I looked into Redux which is by far the most used, with its merits, and easier to have devs to know how to work with it. I really tried to switch my mind to use redux but every time something made me step back from it. Sometimes the boilerplate, sometimes the need to everything (like routing) be managed by redux, sometimes the number of choices to be made...
Mobx is another alternative which sounds less intimidating. So i used this conversion to test how would work in practice. So far has met the demands of allowing to create modern (Reactive) UI with a manageable testable state.
BTW somethings in the RealWorld architecture, inherited by React version, i would do differently like decoupling the state update from the components.
Thanks for the reply. We're also looking into MobX as a solution in comparison with Redux which we find from experience leads to too much boilerplate.
So far I'm intrigued by MobX and based on my initial efforts to integrate into some of our components, I find it quite straightforward to use.
I am a little bit concerned about the 'magic' it is doing compared to Redux which is much more straightforward. But maybe I just need to dig under the covers of MobX a little.
I'm interested if you could clarify what you mean by your last comment:
In general, my experience with building React/web components using state management solutions like Redux/MobX is that they lead you to create components/state that are unfortunately tightly coupled to a specific application scenario and hence are not as easily reusable by different applications.
We work on a large web application that can be thought of as being comprised of many smaller applications/pages and we want our components to be re-usable across many of those smaller applications. So I'm focusing on how we can use something like MobX to allow state to be managed by components without making too many assumptions about how the components might be used together. But it's not sufficient to just keep state in each component as there are scenarios where we do what state to be shared if the components are used on the same page/application part.
See the code below:
github.com/blikblum/lit-element-mo...
I would write as:
The responsibility to call e.g.
articlesStore.loadArticles()should be in a layer above what many call the orchestrator layer. I like having the route as this layer (not component based) but can be separated classes.With this architecture is easier to test the component (just ensure calls the events when appropriate).
This is the core principle of data down, events up pattern
Other things to improve decoupling: move the stores to a instance property instead of a context property and listen to route changes elsewhere
The architecture of the demo is contaminated by React thinking that everything is handled in a component (routing, data loading etc) one of the things why i don't like React.
You can look what i mean by using route like the orchestrator here