Issue subscribing to store changes
I am having trouble understanding why the onClick event of my button in this playground code snippet does not update the UI, if you click on the add sub questions button, it will change the underlying data in the store, but none of the UI elements get re rendered, the error messages from solid playground are not helping either, pls help, here is the playground link https://playground.solidjs.com/anonymous/8675c6e7-3b73-4562-a127-16d43d336f76
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
27 Replies
I didn't see it was sub questions button
the "add sub question" button works for you?
yeah no worries
You need to use setQuestions
You cannot make a new store out another store, the parent store won't react to substore
You can do this trick though
const setQuestion = setQuestions.bind(undefined, index)
yeah u can
Yes but not in the way he is doing it right now I meant
Nah it’s allowed
And the parent store would react to the substore setter?
From what I understand yeah
But I don’t think that’d affect it anyway
I don't see how that's possible but maybe something I don't know
I think the issue is that sub_questions is being set to newQuestion rather than it being added to the previous array value
Yeah that's another thing
Ah never mind that
new question returns an array hmm
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
The issue was the way QuestionUi was using props
Wrong prop names and arguments passed
It's the first time I see this pattern to create a new store on a subtree of another store to have a simpler setter for that sub-tree (and don't use the reader).
It seems suspicious at first glance. Is it a common pattern? Is it documented somewhere that this is supposed to work? Will it work in next versions of solidjs?
The proposed alternative seems more redable to me:
Anyway I'm just curious about that pattern and would like to know if it's commonly used.
First time I've seen it used tbh, but I believe it's documented? Or i read about it in an issue/discord before
How come a createEffect needs to be used btw?
Thanks for the help
it doesn't, I was just testing
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
Yea idk where it’s documented but I’ve seen it used multiple times in this server
To all of those I’m not sure, but from how often I’ve seen it in this server I think it’s ok and sticking around
If you're interested here's a version that uses produce to manage it as a monolithic store
https://playground.solidjs.com/anonymous/f5ae0949-8ede-44c6-bcdf-baf2ff9b978c
https://docs.solidjs.com/reference/stores/store-utilities#produce
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
to be clear the multi-createStore method is also a monolithic store, here's a working version that has a console.log that reacts to nested changes
https://playground.solidjs.com/anonymous/3d4f6dd6-2dab-425f-a0c2-21e216b34143
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
Thanks for the reply. You seem to be a big supporter for this pattern. Admittedly, it's great to have a simplified syntax for the setter function.
My concern about that is readability and maybe performance. Having that
createStore that doesn't create a store is not self explaining code. It also goes through the full overhead of creating a store. Looking at the code the overhead seems mostly about wrapping again the object for accessor.
If this seems a commonly used, I think it would be worthwhile to ask for a feature request for a store helper function for exactly that purpose. It could skip re-wrapping and could be correctly named.yeah there maybe some performance overhead at creation time - i think it'd be the same performance for reading/writing which i think i'd care about more.
i'm curious if a dedicated function for that would be permitted, or even if
createStore could short circuit if it encountered a store with $PROXYMy perspective is that when you take an ostensibly read-only value and then use
createStore() directly on it, effective breaking read-write segregation, you should at least have an uneasy feeling in the pit of your stomach.
Does it matter in this case? Probably not.
But that is primarily because you can remove the questions collection from the question record entirely and have the question component create its own independent questions collection and createStore() around that . At that point the questions collection is just component local storage.
The fact that the question record carries the questions collection suggest app level storage to me.
Refined version of the earlier example:
https://playground.solidjs.com/anonymous/3187434d-de54-4617-9380-b24e86c911f9Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
in addition to read-write segregation, derived stores can easily be broken. just replace the object used for deriving in the source store
here's a comparison of different approaches. you could probably make a nice helper out of them
https://playground.solidjs.com/anonymous/dfb3dc54-6139-4a56-96fb-4d1a45ac2984