Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove EndState? #2

Open
ethanresnick opened this issue Nov 1, 2016 · 1 comment
Open

Remove EndState? #2

ethanresnick opened this issue Nov 1, 2016 · 1 comment

Comments

@ethanresnick
Copy link
Owner

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.

@ethanresnick
Copy link
Owner Author

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".

ethanresnick added a commit that referenced this issue May 8, 2017
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant