You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cons: makes it impossible to distinguish between an async state that is semantically an "end state" and an async state that isn't (i.e., because its async behavior is going to redirect the call eventually), as both can show up as renderable states with no branching.
The text was updated successfully, but these errors were encountered:
Another option: remove isEndState for now, but add it back later as an optional flag on non-branching renderable states in the future iff it becomes necessary/we attach functionality to the semantic idea of an "end state".
1. Remove the concept of an end state and an “abstract renderable
state”. Before, all renderable states were either “abstract” or
realized as “end (renderable) states” or “async (renderable) states”.
This was just too complicated. Now, we can think exclusively in terms
of branching only states (hidden states), renderable only states (end
states and states that’ll be async hijacked), and normal states. Closes#2.
2. Give a static definition of a valid state. I’m not sure how well
this’ll work (b/c idk if typescript can tell enough of the time that a
property is undefined on a state statically), but it’s worth a shot.
Pros: simpler type set. See no-end-state branch.
Cons: makes it impossible to distinguish between an async state that is semantically an "end state" and an async state that isn't (i.e., because its async behavior is going to redirect the call eventually), as both can show up as renderable states with no branching.
The text was updated successfully, but these errors were encountered: