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.
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