Idea: use sagas

[slorber]

Use Sagas

I think a saga can be useful to solve this part:

Business rule: if the current counter value is > 10 AND the button is active, then the counter value is incremented by 2 instead of 1.

The saga can listen for events from the counter (increments), and from the button, and from the gif component, hold some state, and then dispatch increment(1) or increment(2) based on the state hold by the saga.

---

In the backend world, the saga is a piece of software that permits to coordinate long running transactions (eventual consistency), and transactions across different bounded contexts (domain driven design jargon).

It is gaining popularity in frontend world by with redux-sagas from @yelouafi (even if most people only use it now only as a replacement for redux-thunks). See also

To simplify this for frontend world, imagine there is widget1 and widget2. When some button on widget1 is clicked, then it should have an effect on widget2. Instead of coupling the 2 widgets together (ie widget1 dispatch an action that targets widget2), widget1 only dispatch that its button was clicked. Then the saga listen for this button click and then update widget2 by dispaching a new event that widget2 is aware of.

The 2 widgets are now bounded contexts that can live separately. They do not need each others to be consistent and can be reused in other apps as well. The saga is the coupling point between the two widgets that coordinate them in a meaningful way for your business.

[tomkis]

👍

[sibelius]

how do u handle if widget1 and widget2 uses the same action name ( reduxjs/redux#897) ?

[slorber]

@sibelius yes this is a problem and Elm solves it properly. This is why initially I suggested to use 2 Elm mailboxes, one for nested actions to manage local component state, and one for flat business/unique/app-coupled actions