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

captureStoreUpdates — return the full path to the property that changed #576

Open
astoilkov opened this issue Feb 28, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@astoilkov
Copy link

Describe The Problem To Be Solved

I'm migrating from on-change to using captureStoreUpdates().

When using captureStoreUpdates(), setting a new value mutable.settings.model = model will produce the path: ["settings"]. However, if I replace the entire settings object this will trigger more updates than just updating the settings.model property.

Suggest A Solution

I propose for an option or change in behavior where setting mutable.settings.model produces path: ["settings", "model"].

@astoilkov astoilkov changed the title captureStoreUpdates return the full path to the property that changed captureStoreUpdates — return the full path to the property that changed Feb 28, 2024
@astoilkov astoilkov changed the title captureStoreUpdates — return the full path to the property that changed captureStoreUpdates — return the full path to the property that changed Feb 28, 2024
@astoilkov astoilkov changed the title captureStoreUpdates — return the full path to the property that changed captureStoreUpdates — return the full path to the property that changed Feb 28, 2024
@thetarnav
Copy link
Member

captureStoreUpdates is returning the path to the object, not property, by design. It allows to simplify the implementation a lot—there is no easy way of checking which property was changed without cloning each object and diffing it.
It's not properly communicated in the readme, which need to be corrected.
I'm also not against adding another helper for diffing the objects that would wrap captureStoreUpdates. But captureStoreUpdates should remain as is, because getting the changed object is often what you need.

@astoilkov
Copy link
Author

I would choose the simpler implementation as well.

It would be great then to have another helper as well. However, if this isn't something you are interested in at the moment you can close this issue.

Thanks for the detailed explanation!

@thetarnav thetarnav added the enhancement New feature or request label Sep 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants