foolswisdom
any way to update a signal without it causing a reactive update?
It's certainly not possible to prevent an update when calling the setter (untrack works for the read side, so it doesn't subscribe. But you can't set a setter and expect listeners to not update, excluding batch rules which just defer of course )
16 replies
any way to update a signal without it causing a reactive update?
My solution would be to use a regular variable instead, and have the other page actively pull from there when rendering. If you also want to sometimes have reactive updates, then you can write an abstraction that allows controlling whether only the variable gets modified, or if the signal gets updated
16 replies
Lazy loading components work with SSR with solidStart?
It's not quite clear how you want it to behave, but I believe the answer is that lazily imported components will be shipped in ssr mode if they are used, and remaining lazy components will be loaded if the client needs and requests them
4 replies
@solidjs/router not working
It appears to you have your editor set to warn you when misspelled / unknown words are words. solidjs may not appear in the dictionary, but that makes it no less a valid package namespace, and
@solidjs/router is the correct package name. This does not stop your package manager from installing it, or is simply the vscode extension warning that it doesn't know this word23 replies
Unable to provide context to children
It isn't clear where props.children was used. If it's in the same place as where the children are accessed / created in the above code, that would result in the same problem.
Or to restate the issue: the children helper does not change where the creation of children occurs, it's merely a helper to memoize so they're only created once. And the problem is that creating the children in the body of the component, above the jsx, is above the provider boundary.
13 replies
Unable to provide context to children
https://docs.solidjs.com/reference/component-apis/children#children
Towards the bottom (though it sadly doesn't call out the implications for context)
An important aspect of the children helper is that it forces the children to be created and resolved, as it accesses props.children immediately.
13 replies
Unable to provide context to children
The problem here is that the children are created early. Normally, props.children is a lazy access, so the children are created under the context provider boundary. In this case, you're eagerly accessing it in the solidChildren function (it's a wrapper around memo, which is eager). This means you're freaking the children outside the boundary.
13 replies