# Discussion: The limits of actions and reducers

**URL:** https://discuss.prosemirror.net/t/discussion-the-limits-of-actions-and-reducers/551
**Category:** Uncategorized
**Created:** [December 29, 2016, 4:30pm UTC](https://discuss.prosemirror.net/t/discussion-the-limits-of-actions-and-reducers/551 "2016-12-29T16:30:30Z")
**Posts on this page:** 1
**Page:** 2

<div class="post-metadata">

### Author: ![Gozala](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/gozala/32/268_2.png) [@Gozala](https://discuss.prosemirror.net/u/Gozala)
#### Post date: [January 4, 2017, 7:44pm UTC](https://discuss.prosemirror.net/t/discussion-the-limits-of-actions-and-reducers/551/21 "2017-01-04T19:44:21Z")

</div>

> [@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`](http://prosemirror.net/version/2017.01.03.html#state.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.

[Previous page](https://discuss.prosemirror.net/t/discussion-the-limits-of-actions-and-reducers/551.md?page=1)