Add JUMP_TO_STATE action for slider-like monitors #5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I challenged you to implement slider-like custom monitors in #3, but in fact I forget something essential to make it easy.
The built-in
LogMonitor
lets you “toggle” individual actions, disabling them from history. This is not what slider interface is like though: a slider just moves back and forward in time between the computed state. It does not really alter the history: it only alters the current state we are looking at.This PR adds another devtools action:
JUMP_TO_STATE
. By default, thecurrentStateIndex
will advance any time an action is performed, but your custom monitor can also callthis.props.jumpToState({ index: 0 })
to jump to the first state, or something in the middle (make sure to to put there values larger thanthis.props.computedStates.length - 1
.The default
LogMonitor
does not usethis.props.jumpToState
at all, but your custom monitor may use it, as well asthis.props.currentStateIndex
, to implement a slider-like UI.