Show HN: Kea – The power of Redux with the simplicity of MobX

You can just not use the @ syntax for decorators and instead just do it manually like so:

    class Counter extends Component {
        ...
    }

    Counter = kea(...)(Counter);

    export default Counter;

    @kea // kicks off the meta-programming to read the statics below
    export default class Counter extends Component {
      static actions = {
        increment: (amount) => ({ amount }),
        decrement: (amount) => ({ amount }),
      };

      static reducers = {
        counter: [0, PropTypes.number, {
          [this.actions.increment]: (state, payload) => state + payload.amount,
          [this.actions.decrement]: (state, payload) => state - payload.amount
        }],
      };

      static selectors = ({ selectors }) => ({
        doubleCounter: [
          () => [selectors.counter],
          (counter) => counter * 2,
          PropTypes.number,
        ],
      });

      render () {
        const { counter, doubleCounter } = this.props
        const { increment, decrement } = this.constructor.actions

        return (
          <div className='kea-counter'>
            Count: {counter}<br />
            Doublecount: {doubleCounter}<br />
            <button onClick={() => increment(1)}>Increment</button>
            <button onClick={() => decrement(1)}>Decrement</button>
          </div>
        )
      }
    }

2) Indeed there is duplication between action names and the reducers. This however makes it so that you can have many reducers listening to the same actions. E.g. setting `isLoading` to `false` when `actions.resultsFetched` occurs.

It's easy to dismiss these things as "buzzword" soup when the examples are trivial for illustrative purposes, but having real experience employing these patterns at scale is extremely valuable in the real world.

The point was to show what this library is capable of, so that people with the imagination of your imaginary co-worker could extrapolate its usefulness to real world applications.

I have built 3 large applications using kea, and at that scale all these features come in handy.

Why the scare quotes around "promise-based timeout" library? I can guess just by looking at the code that it's a Promise wrapper around setTimeout. It makes the example easier to read, since the API is based around promises and not callbacks. It's probably less than 5 lines of code.

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.

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

MobX is simple to get going, but I fear there are dragons beneath. Here's a small writeup I did about it on Reddit: https://www.reddit.com/r/reactjs/comments/6pni2i/kea_high_le...

That said, I haven't used flow or TS myself and can't confirm nor deny compatibility