These articles showing different approaches for managing state:
4 Likes
I honestly prefer to roll my own solution for most use cases. A singleton class for managing your state with some methods for accessing and mutating state will fit your use case in most situations. The benefit of state management libraries like Redux is they allow you to undo/redo and replay changes made to your data, but that comes at a cost of needing to write your apps in a specific way.
4 Likes
We created our own solution a few times, but when we started to build a developer tool to debug the state we finally gave redux a try. We are really happy with the choise to use redux.
We don’t use it for everything, on some components we still use twoway databinding, but the main state are always managed by redux. We used the articles you provided as input for getting started.
Another tips could be the typescript-fsa packages. They make writing actions and reducers really fun. (But they look reallyt magic the first time you see them, so I suggest go with a simple string as a action the first time). Here’s the link to typescript-fsd-reducer https://github.com/dphilipson/typescript-fsa-reducers
Thanks for asking the question, I would also like to hear how other people are managing state in aurelia.
1 Like
Yeah, I thought if we can write the models correctly it would be enough to handle the state combines with event aggregator/signals from Aurelia.
Using redux is fine too, but as you mentioned we need to follow its rules.
But it’s nice to have people sharing here about how they manage their Aurelia app’s state.
Then the choice back to the developer.
I agree with @dwaynecharrington’s response. We too manage state with a state service which is basically just a singleton so it’s easy to setup at startup and just re-load when necessary throughout the code base.
I imagine it depends entirely on your app.
We’ve got a large aurelia app running on electron, loading files, accessing hardware devices and pushing data into indexedDB. Undo/redo only makes sense in a couple of places and it was simple enough to push those states into a list where required.
Im using the rxjs based approach, as described on my blog, on 4 different projects now and it was so far the best experience given that all async issues like thunks in Redux are a no-brainer. Besides that it integrates nicely with existing old school services