Objects passing through a store are copies, even after unwrapping... why?
I'm attempting to store some objects in a solid store which I need to be able to do reference equality checks against when I pull them out of the store. Is this possible?
15 Replies
How would that help?
I do not believe that would have any effect given the problem
I found that it's
unwrap that is copying the objects I put into my store
I guess I'm back at the point where I can't use the solid store but I could use redux and reconcile...?
It's pretty unfortunate that unwrap does what it does because the objects it copies are already deeply immutable, which is why I care about their identity staying stable
of course there is no way of knowing that an object is deeply immutable without going through it deeply and checking, which is a huge pain
I guess what I have to do is keep an solid store for every view
and then each view's store will be bound to part of the overall immutable redux state
not unlike how things work when you use connect really
Ugh, that still won't work though because it relies on the immutable values passing through the Solid layer for binding, which can't happen because a Solid store destroys them if it touches them
I think the only really stupid way I could hack around this is to map the reference-stable messed up copied values back to the reference-stable original good values. An unwrap-unwrapper, if you will
but it'd just be a huge waste of work : /unwrap does not copy the data
It returns the data that is otherwise behind a proxy
If u could make a minimal reproduction in the solid playground with what you want to achieve it will be easier for us to understand what you are trying to do and give you suggestionsOH. It normally doesn't copy the object, it only does that because these objects are frozen
I see
TIL
Why are they frozen?
The identities of those objects are used to cache some metadata about what is stored in them
if what was stored in the object could change, the cached information could become invalid later
Basically though the data structure I'm working with is a tree made up of nodes wired together with
WeakMap linkages
In general the existence of WeakMap means that it is not necessarily safe to copy any object you don't know, as you may be discarding private informationGiven that the object is frozen does it make any sense to use a store? i.e. expose the top level reference via a signal.
the piece of state is essentially
{ selectedRange: [start, end] }, where start and end are the immutable objects giving me trouble
I am certainly willing to try making signalsRather than thinking in terms of traditional state, distill it down to “what type of changes do I want to react to” and design the reactive graph from there.
Yeah, that makes sense. In this case the change is literally just that the user clicked something, changing the selection. I originally had it as a signal and it worked fine.
for now I just have
Yes I agree with peer, this does not seem like the right place for a store.
here it is working
