Hacker News Reader

Comment by anonymous_sorry | Hacker News Reader

A key thing I've seen people miss is that actions should be triggered by specific transitions, rather than by the States.

For example:

If a pull request goes from Draft->In Review the FSM might perform an "assign reviewer" action.

If a PR goes from Changes Requested->In Review, there is already a reviewer assigned, so it just performs "notify reviewer".

View on HN

There are two different types of state machines that behave differently. Moore machines have actions (or outputs) determined by the state while Mealy machines have actions determined by the specific transitions (or state + inputs).

Depending on the system and implementation constraints one type works better than the other (e.g. Mealy machines can implement Moore machine behavior with one less state, which may save hardware).

My states have entry() and exit() functions that do things like you describe.

Lets say a PR can go from:

Draft->Closed/Abandoned

Draft->In Review

Changes Requested->In Review

I'm not sure "assign reviewer" would fit either in Draft.exit() or InReview.entry(). I guess you'd implement something like "ensure reviewer assigned" in InReview.entry() instead. Which would work, but would itself contain the sort of state-dependent logic that a state machine is meant to surface.

Putting it in the entry is probably what I’d do, or I’d split the “InReview” state into its own sub state machine. It’s hard to reason exactly with imaginary scenarios though.

I would call them two states.

Or, perhaps an additional transitional state.

I think two states is probably a bad idea. Obviously the use case is hypothetical, but I'm assuming the set of transitions available from the In Review state does not depend on the path you took to get there.

Reply on news.ycombinator.com