Discussion: The limits of actions and reducers

Oh I think I misunderstood your solution. I sort of assumed that instead of message transaction:Transaction is passed to plugin reducer / update functions where each can then further ammend changes to it, like plugin A could do transaction.setSelection(...) and plugin B could ammend another change say transaction.addStoredMark(...) and finally after all plugins get to contribute changes transaction would be passed to host reducer / update.

In that case only thing that changes conceptually is that all followup messages are applied in the same cycle vs separate ones.

Adding transactions system is a good idea, I might incorporate into my implementation used currently as well :slight_smile:

It is just I misunderstood your solution as described above. In which case plugin A would have never known that B added transaction.addStoredMark(...) change to the transaction.

This is partially why in Elm followup messages happen in separate cycles that also happen in separate turns of event loop, although that have other drawbacks.

Anyway, Iā€™m happy I could help.