-
Notifications
You must be signed in to change notification settings - Fork 30
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
Added entry & exit function support #37
base: master
Are you sure you want to change the base?
Conversation
The changes allow each state to have an `_entry` and an `_exit` handler that acts as a special transition that executes on entry into, or exit from a state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a decent idea.
- Code changes
- Adding a test covering the changes (probably 👉 https://github.com/krasimir/stent/blob/master/src/__tests__/index.spec.js)
- Updating the docs
I'm fine dealing with the last bit but can you add a test coverage of the changes.
@@ -24,10 +25,23 @@ export default function updateState(machine, state) { | |||
throw new Error(ERROR_UNCOVERED_STATE(newState.name)); | |||
} | |||
|
|||
var handler = machine.transitions[machine.state.name]['_exit']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use @exit
and @enter
instead of _exit
and _entry
. It seems more intuitive for me. What you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not tied to any specific terminology. We could use @exit
and @enter
- but I see the @ symbol potentially being potentially problematic. The _
was more based on my understanding of the convention being used in JS to represent 'private' members/methods.
I like the Would it also make sense to omit those internal-use actions from the final machine methods, i.e., the machine should not have |
@illarionvk what are your concerns about having those defined. They'll be actually |
The camelcasing transform would rename the methods to I think having literal non-camelcased const noop = function() {}
const config = {
state: IDLE,
transitions: {
[IDLE]: {
"@exit": function() { ... },
init: function() { ... }
},
[INITIALIZING]: {
"@enter": function() { ... },
noop
},
[READY_TO_PROCESS]: {
enter: function() { ... }
},
[PROCESSING]: {
exit: function() { ... }
},
[DONE]: {
noop
}
}
};
// The config should produce an instance similar to the type below
type MachineInstance {
...Machine,
'@enter': () => void,
'@exit': () => void,
'enter': () => void,
'exit': () => void,
'init': () => void,
'noop': () => void,
} |
Yes @krasimir I will add the tests. |
@illarionvk is completely right. We have to think about how the API will look like. The helper here will indeed remove the |
…t conflicts with the real stent
The changes allow each state to have an
_entry
and an_exit
handler that acts as a special transition that executes on entry into, or exit from a state.