#Issue subscribing to store changes

36 messages · Page 1 of 1 (latest)

turbid stirrup
#

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

fair tartan
#

I didn't see it was sub questions button

turbid stirrup
#

the "add sub question" button works for you?

#

yeah no worries

fair tartan
#

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)

vale field
fair tartan
#

Yes but not in the way he is doing it right now I meant

vale field
#

Nah it’s allowed

fair tartan
#

And the parent store would react to the substore setter?

vale field
#

From what I understand yeah

#

But I don’t think that’d affect it anyway

fair tartan
#

I don't see how that's possible but maybe something I don't know

vale field
#

I think the issue is that sub_questions is being set to newQuestion rather than it being added to the previous array value

fair tartan
#

Yeah that's another thing

vale field
#

Ah never mind that

fair tartan
#

new question returns an array hmm

sudden island
#

The issue was the way QuestionUi was using props

#

Wrong prop names and arguments passed

heady zealot
# vale field Nah it’s allowed

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:

const setQuestion = setQuestions.bind(undefined, index)

Anyway I'm just curious about that pattern and would like to know if it's commonly used.

sudden island
#

First time I've seen it used tbh, but I believe it's documented? Or i read about it in an issue/discord before

turbid stirrup
#

Thanks for the help

sudden island
vale field
vale field
compact prawn
vale field
heady zealot
# vale field To all of those I’m not sure, but from how often I’ve seen it in this server I t...

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.

vale field
#

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 $PROXY

compact prawn
#

My 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-b24e86c911f9

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

scarlet cypress
#

in addition to read-write segregation, derived stores can easily be broken. just replace the object used for deriving in the source store