6 ms·

Shameless plug for another take on the same promise: https://github.com/jnorth/megalith https://github.com/jnorth/megalith I think most people who are attracte

by north 9y ago

Shameless plug for another take on the same promise: https://github.com/jnorth/megalith https://github.com/jnorth/megalith 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.

aidos 9y ago
Looks nice. Seems to do a good job of making the code easy to read. I'm assuming you started this before mobx state tree? It looks very similar. After much experimentation, MST is where I've decided to spend my time. Like your library, the code ends up readable.
- north 9y ago
  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.
  - aidos 9y ago
    I guess you miss out on all the nice mobx stuff too (computed properties etc). Having said that, I have to commend you. Your state library is the cleanest I've seen in terms of the user land code. There's nothing in the examples that feels like framework noise.
    - north 9y ago
      Thanks! 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 :)
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.

by north 9y ago

aidos 9y ago

Looks nice. Seems to do a good job of making the code easy to read. I'm assuming you started this before mobx state tree? It looks very similar. After much experimentation, MST is where I've decided to spend my time. Like your library, the code ends up readable.

north 9y ago
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.
- aidos 9y ago
  I guess you miss out on all the nice mobx stuff too (computed properties etc). Having said that, I have to commend you. Your state library is the cleanest I've seen in terms of the user land code. There's nothing in the examples that feels like framework noise.
  - north 9y ago
    Thanks! 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 :)

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.