Transaction creates a black box that is able to wrap any method such that certain invariants are maintained before and after the method is invoked (Even if an exception is thrown while invoking the wrapped method). Whoever instantiates a transaction can provide enforcers of the invariants at creation time. The Transaction class itself will supply one additional automatic invariant for you - the invariant that any transaction instance should not be run while it is already being run. You would typically create a single instance of a Transaction for reuse multiple times, that potentially is used to wrap several different methods. Wrappers are extremely simple - they only require implementing two methods.

                      wrappers (injected at creation time)
                                     +        +
                                     |        |
                   +-----------------|--------|--------------+
                   |                 v        |              |
                   |      +---------------+   |              |
                   |   +--|    wrapper1   |---|----+         |
                   |   |  +---------------+   v    |         |
                   |   |          +-------------+  |         |
                   |   |     +----|   wrapper2  |--------+   |
                   |   |     |    +-------------+  |     |   |
                   |   |     |                     |     |   |
                   |   v     v                     v     v   | wrapper
                   | +---+ +---+   +---------+   +---+ +---+ | invariants
perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
+----------------->|-|---|-|---|-->|anyMethod|---|---|-|---|-|-------->
                   | |   | |   |   |         |   |   | |   | |
                   | |   | |   |   |         |   |   | |   | |
                   | |   | |   |   |         |   |   | |   | |
                   | +---+ +---+   +---------+   +---+ +---+ |
                   |  initialize                    close    |
                   +-----------------------------------------+

Use cases:

• Preserving the input selection ranges before/after reconciliation. Restoring selection even in the event of an unexpected error.
• Deactivating events while rearranging the DOM, preventing blurs/focuses, while guaranteeing that afterwards, the event system is reactivated.
• Flushing a queue of collected DOM mutations to the main UI thread after a reconciliation takes place in a worker thread.
• Invoking any collected componentDidUpdate callbacks after rendering new content.
• (Future use case): Wrapping particular flushes of the ReactWorker queue to preserve the scrollTop (an automatic scroll aware DOM).
• (Future use case): Layout calculations before and after DOM upates.

Transactional plugin API:

• A module that has an initialize method that returns any precomputation.
• and a close method that accepts the precomputation. close is invoked when the wrapped process is completed, or has failed.