Let effects return the `actions` object

Actions are functions you call like actions.myAction(data). When you call an action, HyperApp checks if it belongs to effects or reducers, then:

• for reducers
  • applies the reducer to update the model, newModel = reducer(oldModel, data)
• for effects
  • calls the effect effect(data)

Finally, the action function returns (undefined).

The proposal is, amend the previously described behavior, and return the actions object instead.

This would allow chaining effects / reducers.

Effects

Effects, can be asynchronous, so we must return a Promise to make sure they are executed in order.

actions.myReducer1().myReducer2().myEffect1().then(actions.myEffect2).then(actions.myEffect3)

app({
    effects: {
       bigEffect: async (model, actions, data) => {
           actions.myReducer1().myReducer2()
           await actions.myEffect1()
           await actions.myEffect2()
           actions.myReducer3().myReducer4()
        }
    }
})

Reducers

Reducers are sync, so there’s no need to return a promise in this case.

actions.myReducer1().myReducer2()

Notes

• Chaining reducers should be limited to reducers, otherwise you’d end up using them like an effect which is wrong. Why? Because reducers cause the view to be re-rendered.
• There’s no need to re-render after each reducer, so this mechanism should try to be efficient. Also related: https://github.com/hyperapp/hyperapp/issues/90

[rbiggs]

I think sticking as closely as possible to the Elm Architecture is the biggest selling point, otherwise it will become like CycleJS.

[jorgebucaran]

It shouldn’t if we’re using requestAnimationFrame, but TBH I don’t know if I’d like to proceed with this feature, it seems it creates more of an anti-pattern than anything else.

The thing, sometimes you’d like to run several reducers, so instead of:

actions.one()
actions.two()
actions.three()

you could do:

actions.one().two().three()

Effect actions, return what your effect function returns, so you can return a promise which is fine.