Hacker News Reader

Comment by north | Hacker News Reader

Shameless plug for another take on the same promise: 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.

View on HN

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!)

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

https://github.com/mobxjs/mobx-state-tree#creating-async-pro...

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.

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 :)

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

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.

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

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 :)

Reply on news.ycombinator.com