-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Immutable option/configuration for Stores #1146
Comments
I've wondered about this. The relevant code is here — it could be as simple as adding a export function differs(a, b) {
return a !== b || ((a && typeof a === 'object') || typeof a === 'function');
}
export function differsImmutable(a, b) {
return a !== b;
} ...and using the immutable version if a compiler option was set, the same way you can opt into
const store = new Store({ some: 'data' }, { immutable: true }); ...and it would use |
Adds optional performance support for apps using an immutable data structure such as redux. Adds the `immutable` boolean option for compile and an `immutable` option to store as well. When these options are used, computed will not recompute if the object has not changed. If your data structure is not immutable you should not use this as svelte cannot know if a mutation was made on objects. This PR also adds support for Dates and NaN values so computed properties will not recompute if a date has not changed or a value did not change from NaN. This closes out these issues: * sveltejs#1146 * sveltejs#1161 This is my first PR for Svelte. Any feedback would be appreciated!
This is released as 1.55 — thank you! |
It would be great if Store (and Store/Svelte's computed properties) could have a configuration option to make it un-conservative when it is known the data will be immutable. That is, make it assume objects never mutate and make the comparisons always treat values as immutable.
I have a data store that is immutable (like Redux) and this could help with performance, particularly with computed properties that perform calculations with objects and arrays as inputs. Array sorts and other slower data computations could be calculated just once when their value changes instead of every time any value is changed.
In the docs there is a note that "Store is conservative about objects and arrays, because there is no easy way to know if they have been mutated." If you know in your application your store only holds immutable data, this could be a nice improvement.
Questions this raises:
The text was updated successfully, but these errors were encountered: