Scheduled Actions?

[dts]

I am trying to migrate a http://machina-js.org/ based state machine system to a redux-based store. The biggest question I've had so far is about the notion of "scheduled" actions. I've only been looking for "scheduled actions redux" on google, because I can't think of any better terms, so forgive me if I didn't think of the term of art!

In a "stoplight" state machine example (the standard one for machina), the state might follows these steps: green -> yellow (8 sec) -> red. My thought is to encode it with a STATE_CHANGE action. To get to red, we must first go through yellow for 8 seconds.

I want to be able to serialize the state at any given time, deserialize it after some time, and have the desired timing hold true (in the above example, reload the page in the yellow phase). Encoding the actions in the state has some advantages and disadvantages. Namely, we need to dispatch some kind of DISPATH_SCHEDULED_ACTION action. "Cyclic" or "repeating" actions might have two fields, indicating the next time, the interval duration, and the number of repeats.

It feels "wrong" to encode actions in the state, but I can't think of any real reasons why it's a bad idea - they are in fact part of the state in my example.

Thoughts?

[johnsoftek]

Have you looked at redux-saga? It is the missing piece of redux, IMO. redux
handles (state, action) => state. redux-saga handles the event patterns of
the app.

On 29 December 2015 at 16:56, Daniel Staudigel [email protected]
wrote:

I am trying to migrate a http://machina-js.org/ based state machine
system to a redux-based store. The biggest question I've had so far is
about the notion of "scheduled" actions. I've only been looking for
"scheduled actions redux" on google, because I can't think of any better
terms, so forgive me if I didn't think of the term of art!

In a "stoplight" state machine example (the standard one for machina), the
state might follows these steps: green -> yellow (8 sec) -> red. My thought
is to encode it with a STATE_CHANGE action. To get to red, we must first
go through yellow for 8 seconds.

I want to be able to serialize the state at any given time, deserialize it
after some time, and have the desired timing hold true (in the above
example, reload the page in the yellow phase). Encoding the actions in the
state has some advantages and disadvantages. Namely, we need to dispatch
some kind of DISPATH_SCHEDULED_ACTION action. "Cyclic" or "repeating"
actions might have two fields, indicating the next time, the interval
duration, and the number of repeats.

It feels "wrong" to encode actions in the state, but I can't think of
any real reasons why it's a bad idea - they are in fact part of the state
in my example.

Thoughts?

—
Reply to this email directly or view it on GitHub
#1187.

[dts]

Yes!!! That is precisely the abstraction that I was looking for - and the @gaearon's suggestion in redux-saga/redux-saga#5 describes the future of this process more generally. Being able to describe long-running processes linearly and testably is huge. Thanks for the suggestion - I'm gonna close this out!