Exclude store property from `unwrap` or from being watched
When updating a SolidJS store, the entire
next state of the store gets unwrapped (for example by updateArray()). Let's say the store is an array of objects, and each object has a data property which is a really big array. Unwrapping each of these arrays adds up to a very noticeable slow down every time the store is updated. Is there a way to exclude this property from being unwrapped, or from being "watched" by SolidJS? Thanks.17 Replies
The store setter is capable of doing fine grained updates.
Alternately there also is
reconcile and produce.I am using
produce, but either way (as far as I could tell from reading the code) the flow begins in setStore then batch then runUpdates then eventually what I describedWhat happens if you apply the change directly, using path syntax (as specifically as possible), instead of using
produce.When updating a SolidJS store, the entire next state of the store gets unwrapped (for example by updateArray()).not sure I am following here. are you unwrapping the store in
updateArray()?
if so, why are you unwrapping it and not using the proxy?@peerreynders I don't know how to use the path syntax, I'm not familiar with the concept, found the tutorial very limited, didn't have the time to play with it and ended going with
produce because it required less adaptation in the existing project. I would greatly appreciate an example or a link 🙂
@bigmistqke I am not unwrapping the store myself, the internal updateArray() function does thatSame link as in my first post
https://docs.solidjs.com/concepts/stores#path-syntax-flexibility
It lets you drill down to the part you want to modify.
@peerreynders thanks. That's the same page I'm familiar with but I don't find the example clear enough. Either way, correct me if I'm wrong, path syntax doesn't cover adding or removing elements, right?
Oh, excuse me, I realized just now that right below the picture example there's code examples of more patterns
Parts are removed by setting
undefined! and parts can be replaced.
And as it shows
https://docs.solidjs.com/concepts/stores#store-updates-with-produce
you can even use produce on a small part of the store.Thanks. Where can I read more about the
undefined! usage?
And does the path format follows any kind of common standard through which I can more about it?https://docs.solidjs.com/reference/store-utilities/create-store#setter
Set values tohttps://docs.solidjs.com/concepts/stores#path-syntax-flexibilityundefinedto delete them from the Store. In TypeScript, you can delete a value by using a non-null assertion, likeundefined!.
arguments are used to specify the keys that lead to the target value you want to modify, while the last argument provides the new value.
Got it, thank you very much. I'll give it a go!
In the simplest case something like
one.two.three = 4;
is represented as
setStore('one', 'two', 'three', 4);
or even
Thanks, it finally clicked, and I can see how it can be used to solve my issue. Back to my original question however, is there any way to tell a SolidJS store to "ignore" some property? Couldn't find anything of the sort by looking at the code
If you want to ignore it, why is it in the store?
Stores are usually shaped for optimal access rather than just wrapping some arbitrary data object.
So it's not unusual to transform the shape of incoming data into something that is more optimal to consume downstream.
Also don't get roped into the "single source of truth" narrative. Keep unrelated data in separate stores.
Indeed. Basically I came into this discussion with the mindset that if what I'm asking is not possible, I will simply have to move that property somewhere else
I have received many useful advices so far, and learned a lot. That's very appreciated. As for my original question, is it or is it not possible?
The intention is for the entire store to be reactive, so no. In terms of implementation there is a Proxy between the consumer and the data and every access to some part of the store results in a reactive subscription to that exact part of the store. So all parts of the store are treated the same.
Got it. That's good to understand. I appreciate your input and patience. This is what I understood from reading the code but it's a confirmation I hadn't missed a higher level interface or abstraction. Thank you.