peerreynders
createEffect vs createEffect + on
The thing that tends to be overlooked by newcomers is fine-grained reactivity. fine-grain change will not trigger coarse-grained reactivity. The way tracking works, you only subscribe to the exact value that you actually access.
“You accessed this value last time so I'll run you again the next time that value changes”. With primitive values it very clear when the value changes.
When it comes to objects and arrays however “the value” is the object reference. If you don't explicitly access their content under a tracked context then Solid's tracking doesn't know that you are interested in changes of the content.
31 replies
createEffect vs createEffect + on
If you make the following change:
You'll see this:
The first timeout replaced
undefined
with an entirely new object—therefore both effects fired.
On the second timeout the first effect doesn't actually see a new object reference; it's identical to the last one—what it is reacting to is that the “guts” of the object have been replaced.
The second effect only specifically is subscribed to changes to the object reference. Given that the object reference doesn't change on the second timeout the effect doesn't run.31 replies
createEffect vs createEffect + on
Any chance you could replicate it here?
https://playground.solidjs.com/anonymous/d72eb037-7569-4225-b447-3faba1f7d58b
I'm wondering whether it has something to do with how you modify the store.
The first version will subscribe you to changes to anything along the path of the proxy necessary to get access to the final value.
The second version will run the dependency function under the same circumstances but I believe that the effect function will only run when the
config
object reference changes.31 replies
Would this break reactivity?
Ripping apart an object and reassembling another just to access a single property isn't great form.
If you require the “object ergonomics” then put in the work to create a reactive object with getters.
As such it's the idiom that
props
use and is practised frequently.
Personally I start with utility functions and often don't get to the point where I have need for the object as a bag of methods semantics
All these really are, are derived signals.
Alternately if your pattern of usage is to capture the session result
inside memo/effect functions to be (synchronously) shared throughout their logic then use:
5 replies
Clearing form after action in solid-start
You can specify an
onComplete(submission)
handler on the action options which could be leveraged in that capacity.
I was added for @solidjs/router
0.15.03 replies
Getting Page Title
Step back for a moment and think.
If you have to get the title that way then you have a solution/architectural problem, not a Solid problem.
Given that the app is driving the content of that title, any part that needs access to that information should already have it; if it does not then the current approach isn't fit for purpose and needs to be re-thought.
3 replies
Solid Start Internal Fetch
Because of the Vinxi layer I believe $fetch doesn't work in Dev which means it doesn't really work.https://discord.com/channels/722131463138705510/910635844119982080/1342244356844814498 The way I'm reading the room is that at this particular point in time “minimizing vinxi” is the top priority for the joint SolidStart/TanStackStart project. By extension fixing internal
$fetch
(or accepting PR's to the that regard) isn't really a priority until that “minimization effort” has been completed; $fetch
being broken right now means it doesn't have to be fixed because nobody can rely on it right now anyway.7 replies
Need help understanding preload and file conventions
Just a preview to some stuff you're going to encounter.
The
preload
function is not meant to be async
. It's passed RoutePreloadFuncArgs
so that it can synchronously derive arguments intended for query
wrappers.
While these wrappers are async
, preload
doesn't await
them; the intent is to “warm” the query
's so that the page being navigated to can get the response payload ASAP.
The components on the page access query
wrappers via createAsync
. At this point the query
wrappers serve request/response deduplication (don't make the mistake of thinking of it as a cache; it's not); multiple components on the page can access the response payload of the same query
(each with its own createAsync()
).
Whether or not the query
holds a resolved or rejected promise, it doesn't matter until at least one of the those consuming createAsync
s accessors is used somewhere; this is typically within the JSX.
If the query
just holds data, the JSX will render with that data. If the accessor however gets an Error
, the error is thrown to the next highest ErrorBoundary
which will then render it's fallback.
You can use HttpStatusCode
in JSX to set the status for an SSR page.4 replies
Multiple actions with different unique names seem to trigger each other's submission.result effects
The router has exactly one submissions queue.
Submissions are matched by their
url
to the base
of the action function.
Given that both myAction1
and myAction2
use exactly the same action function goAction
, their base
URL is identical.
The myAction1
and myAction2
names only come into play during hydration for forms. Other than that the actions are identical (in terms of the client/server relation they do exactly the same thing).
So what is happening here is that submissions
tracks goAction
invocations, not myAction1
or myAction2
submissions.
That is why in my example I used the submission arguments to discriminate between “action 1” and “action 2” submissions. Only when the effect saw that the outbound submission arguments were tied to the component's instance did it even subscribe to the next inbound result
from that particularsubmission
instance (and given that there may not be a result
but an error
that had to be subscribed for as well; finally the submission was clear
ed so it wouldn't hang around and be accidentally referenced later again).
If I had to track multiple concurrent submissions I'd probably make the first submission argument a correlation identifier to cut down on potential confusion.7 replies
Solid Start Internal Fetch
As far as I can tell If you use
- core
use server
functions and then
- wrap those with API routes
the need for an internal fetch mostly goes away because server code can use "use server"
functions without overhead.
Design-wise it's a re-framing from defaulting to API routes and instead focusing on server functions that can support API routes as well for non-SolidStart clients.7 replies
Why are both class and classList needed?
See: https://discord.com/channels/722131463138705510/722131463889223772/1247563450293551125
TL;DR: ignore
classList
and the functionality supported by it.3 replies
Multiple actions with different unique names seem to trigger each other's submission.result effects
You really can't understand this stuff until you start messing with
useSubmissions
(plural).
https://stackblitz.com/edit/solidjs-templates-7u2yad?file=src%2Fapp.tsx7 replies
SSR blank page
instead of waiting for the data called in the queries?SolidStart's default SSR behaviour is to render synchronously what it can and stream the rest in via seroval via a streaming response to the initial request (which I did mention earlier, here).
58 replies