Allow a custom merge method
See original GitHub issueCurrently, when a action return a new state, this one is merged with the previous state. That make the object “state” to grow but never shrink. I would imagine this behavior to be configurable with a pure function. where the default would be:
const mergeState = (previousState, newState) => ({...previousState, ...newState});
To have the same behavior as redux for example, we can use this function
const mergeState = (previousState, newState) => newState;
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:11 (8 by maintainers)
Top Results From Across the Web
Customizing the behavior of cached fields - Apollo GraphQL
You can use a merge function to intelligently combine nested objects that are not normalized in your cache, assuming those objects are nested...
Read more >Merge methods - GitLab Docs
The merge method you select for your project determines how the changes in your merge requests are merged into an existing branch.
Read more >About merge methods on GitHub
To squash and merge pull requests, you must have write permissions in the repository, and the repository must allow squash merging. commit-squashing-diagram.
Read more >Custom Merge Function in R - Stack Overflow
Basically doMerge tells you the lines that require merging (just set up a sequence running from each startpt to the corresponding endpt )....
Read more >Salesforce Merge Custom Object Records: 2 Easy Methods
Unfortunately, Salesforce does not allow users to combine custom objects on its platform. But several secondary apps can help Salesforce merge ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I like the idea of non-merged state. I know merged state has it’s own pros, but merging doesn’t really help me with my own apps.
If I have some state like this and and I want to update the state.
I won’t be able to. I’d have to set
bar
tonull
myself to denote that it’s “removed”.And of course, as your state gets more complex, it’s not as easy as setting a single prop to
null
.It’s not a “con” per se. It’s just a way I would prefer to build my apps. Imo, when being able to replace a state object “wholesale” like this, it’s easier to read and less code to write, both with actions and in views.
Right now a way around this is to just put everything one level deeper to avoid the merge.
When state wasn’t immutable, I’d imagine leaving “removed” state as null would be a perf gain, as you wouldn’t need to constantly, remove and re-create that prop, but now that everything is immutable, there’s not anything to gain, perf wise.
I don’t consider this to be remotely critical, but I would reconsider if it was. However, none of the answers has been able to justify adding this, so I am gonna go with @okwolf’s and avoid us option paralysis.
EDIT: If this turns out to be relevant to implementing something important in the future, I am happy to reopen and add it.