Yeah, right now, state that shouldn't be saved (like computed properties) can be added as regular object properties (i.e. not a part of the initialState), and updated by listening for action events.
I've been thinking of ways to make that a little easier, possibly by having "reactions" that execute in response to actions. But I haven't had the need in my own projects yet, and like to err on the side of a smaller API footprint :)
Right, maybe I called out the wrong part of your example. redux-saga gives a really elegant way to describe the flow, but I feel at the expense of wrapping the async code with special helpers (call, put, fork, etc). You have to learn a few extra concepts for it to be comfortable. Async code in MST and megalith interact a bit more directly with the stores.
One thing I tried to do with megalith is mapping ideas from Redux to built-in language features as much as possible. An action object can trivially be represented as a function call for example—action name and payload is mapped to function name and arguments.
I think Mobx gets into trouble there by building off of observables—you have to litter your async code with different types of action markers to keep state consistent. MST tries to corral all those variations down into a smaller set, where the Redux ecosystem is layering ideas on top of an small initial core. Megalith and MST are starting from two completely opposite sides, but end up looking very similar somewhere in the middle :)
This example doesn't cover all the cases you're showing above, but in megalith or MST you would typically have a clearer separation between the functions that change state and the async communication parts.
Yeah, if I was starting today I might end up with MST as well. The only real benefit of megalith right now would be its size (5k vs 45k). You do get more features for that size though, like integration with the Redux toolset.
I think most people who are attracted to Redux's core principals but want a more opinionated structure will end up gravitating towards mobx-state-tree though.
Nice write-up. I think it could be a pretty interesting thing for people that don't interact via status updates very often, like me. Can you set permissions on the timeline per user/group?
Yeah, right now, state that shouldn't be saved (like computed properties) can be added as regular object properties (i.e. not a part of the initialState), and updated by listening for action events.
I've been thinking of ways to make that a little easier, possibly by having "reactions" that execute in response to actions. But I haven't had the need in my own projects yet, and like to err on the side of a smaller API footprint :)