Discussion: The limits of actions and reducers

[Gozala]

@marijn

It’s rather that transactions can contain plugin-specific extra messages, which are handled (by the plugin) at conceptually the same moment as the rest of the transaction, so that the whole update (core state + plugin state) happens in one shot. This was somewhat inspired by the plugin message/core message split in your example.

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.

@marijn

Whenever an update is spread out over multiple transactions, there will be intermediate states in which some part of it have been applied an other haven’t. Any code looking at that intermediate state might go wrong because the separate fields of the state might not be coherent.

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

@marijn

You have a typo there but I assume you mean that there’s a risk of a transaction slipping through due to the order in which plugins get to look at it. I specifically designed this to avoid this: A transaction only goes through if no plugin cancels it. Transactions can’t be updated, only canceled, before they are applied

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.

@marijn

This could land you in an infinite loop, if two plugins keep responding to the other’s transactions by appending another, but I guess that’s relatively unlikely, and the guarantee that you can see every transaction is really useful.

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.