-
-
Notifications
You must be signed in to change notification settings - Fork 188
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
Allow filtering state properties before save it to history #237
Comments
I also have a use case for this, any status on this? |
You can include the feature using git sub-modules. Create a folder
In
Last, fetch the submodule: git submodule update --init --recursive Every time someone clones your repo, he needs to also fetch the submodules using:
|
Apologies for the delayed response. I see the use case for this addition and that you put some work into submitting a PR. However, I think I see another solution using existing features of redux-undo. You mentioned you couldn't use This could be as simple as case 'UPDATE_NODE_POSITION':
// Update the position. This action is filtered and not added to history
return { ...state, nodes: updatedNodes, selectedNode: action.selectedNodeId };
case 'COMMIT_NODE_POSITION':
state = { ...state, selectedNode: null };
return state;
// Now there should be no "tainted" state that will break the app on undo, redo
// ...
undoable(reducer, { filter: includeAction(['COMMIT_NODE_POSITION', '...']) }); I think something along those lines should work for your use case. If not, we can certainly discuss this addition further. Though if it does need to be added, we should change the name Also, I am working on a change that should allow users to get an easy hook into the state in a more general way. You can see the initial API I have in mind here. Thanks for your patience 👍 |
Intro
The current version
1.0.0-beta9-9-7
does not provide a solution to customize the current state before saving it to history (thoughtinsert
). This is a crucial feature when we have a complex reducer with high update rate. In such cases, we can't break the reducer to multiple parts orfilter
out actions, cause the coupling between them is high. Such use cases can be found in graphic applications where the trigger of an operation dispatch multiple actions. Consider the following example:Use case: A simple graphic app
Bellow is a simple HTML canvas
Pressing down the
n
key in our keyboard allow us to create nodesWe can select a node by clicking on it
We can create a temporary arrow by holding down the SHIFT key
By clicking another node, when have already selected one, we can create an edge between the two nodes
Dragging one node dispatch two actions: one to update the position of the selected node and one to redraw the arrow
Here is a simple state representation of the above use case:
The problem
The difficult part to manage the above state is when the properties relate to each other. Consider that the user has selected a node, this action updates the
selectedNode
property, and decides toUNDO
. What will happen is that theselected
node will be saved to the history as is. When the user dispatchREDO
, the state now can be entirely different, due to reasons outside the Redux store. This might break the whole app.Solution
The solution to the above problem is to reset the
selectedNode
property tonull
before save it to the history.What I propose is to add one more property
filterStateProps
to the configuration ofundoable
enhancer. The property will be an functionfilterStateProps (currentState)
with a parameter to the current unsaved state, i.e. the state before inserting it to history. The return value will be the final state that will be saved. Here is an example using this solution:This approach has a number of advantages:
I strongly believe that a feature like this can make the difference when working with apps that require frequent updates. I have already implemented and tested this approach to my own projects and works beautifully.
The text was updated successfully, but these errors were encountered: