Currently in lots of sub-phase ordered move progressions, the last move is to StartPhase with the next-subphase to go to.
In many cases, especially for Dialog style sub-flows, the default is to StartPhase for the default value of your parent, and if you forget to then the logic won't work in a way that is hard to detect.
You can imagine behavior in AddOrderedForPhase that checks to see if the last move in the entire list of configs is a StartPhase move or a NoOp. If it's either then it doesnt' do anything; if it's neither then it automatically adds a StartPhase for the parent Phase value's DefaultValue. The NoOp is a signal of "I did that on purpose."
A lighter-weigh thing is for AddOrderedToPhase to do this check and simply error if it's not configured correctly, asking the user to end with a NoOp if they did that intentionally.
jkomoros
commented
6 years ago
Currently in lots of sub-phase ordered move progressions, the last move is to StartPhase with the next-subphase to go to.
In many cases, especially for Dialog style sub-flows, the default is to StartPhase for the default value of your parent, and if you forget to then the logic won't work in a way that is hard to detect.
You can imagine behavior in AddOrderedForPhase that checks to see if the last move in the entire list of configs is a StartPhase move or a NoOp. If it's either then it doesnt' do anything; if it's neither then it automatically adds a StartPhase for the parent Phase value's DefaultValue. The NoOp is a signal of "I did that on purpose."
A lighter-weigh thing is for AddOrderedToPhase to do this check and simply error if it's not configured correctly, asking the user to end with a NoOp if they did that intentionally.
Inspired by work while finishing up #627