5 ms·

If my favorite part of redux is structuring flows with redux-saga, does mobx-state-tree have a solution for me? For example, this is nice: // On login, spin

by arstin 9y ago

If my favorite part of redux is structuring flows with redux-saga, does mobx-state-tree have a solution for me? For example, this is nice: // On login, spin off the auth process. If an error or a logout happens, clean up. // Be sure to cancel any pending auth request! // Then get ready for a new login. function* loginFlow() { while (true) { const {user, password} = yield take('LOGIN_REQUEST') const task = yield fork(authorize, user, password) const action = yield take(['LOGOUT', 'LOGIN_ERROR']) if (action.type === 'LOGOUT') yield cancel(task) yield call(Api.clearItem, 'token') } } (Genuine question...idk!)

aidos 9y ago
MST doesn't have the same restrictions as redux in terms of async so you don't need to do it in the same way. Edit: In MST it would look more like plain js: class AuthStore() { .... { login() { do_async_thing() .then(this.postLoginStuff) .catch(this.handleFailedLogin) }, logout() { // do logout stuff } } }
north 9y ago
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. https://github.com/jnorth/megalith/blob/master/docs/examples/async-actions.md https://github.com/jnorth/megalith/blob/master/docs/examples... https://github.com/mobxjs/mobx-state-tree#creating-async-processes https://github.com/mobxjs/mobx-state-tree#creating-async-pro...
- arstin 9y ago
  Yeah, I also like to use redux with a clear separation between actions that change state and those that don't. (For example, reducers only take actions prefixed by DATA_ or UI_, all other actions...the bulk of them really...don't have anything to do with changing state and are handled by other processes. But because of this I don't bother with action creators, so what do I know!) A conceptual appeal of mobx to me is that this distinction seems baked in. The original mobx didn't click with me like redux did ¯\_(ツ)_/¯, but if MST gives transactional updates and support for redux dev tools (right?) could be worth trying.
  - north 9y ago
    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 :)

by arstin 9y ago

aidos 9y ago

MST doesn't have the same restrictions as redux in terms of async so you don't need to do it in the same way. Edit: In MST it would look more like plain js: class AuthStore() { .... { login() { do_async_thing() .then(this.postLoginStuff) .catch(this.handleFailedLogin) }, logout() { // do logout stuff } } }

north 9y ago

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. https://github.com/jnorth/megalith/blob/master/docs/examples/async-actions.md https://github.com/jnorth/megalith/blob/master/docs/examples... https://github.com/mobxjs/mobx-state-tree#creating-async-processes https://github.com/mobxjs/mobx-state-tree#creating-async-pro...

arstin 9y ago
Yeah, I also like to use redux with a clear separation between actions that change state and those that don't. (For example, reducers only take actions prefixed by DATA_ or UI_, all other actions...the bulk of them really...don't have anything to do with changing state and are handled by other processes. But because of this I don't bother with action creators, so what do I know!) A conceptual appeal of mobx to me is that this distinction seems baked in. The original mobx didn't click with me like redux did ¯\_(ツ)_/¯, but if MST gives transactional updates and support for redux dev tools (right?) could be worth trying.
- north 9y ago
  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 :)