Dev Agrawal
@devagr.bsky.social
He/Him
Content Creator, Software Architect
Core team @solidjs.com
Organizer @momentumdevcon.com
youtube.com/@devagr
twitch.tv/devagrawal09
Content Creator, Software Architect
Core team @solidjs.com
Organizer @momentumdevcon.com
youtube.com/@devagr
twitch.tv/devagrawal09
all of that is in the pipeline for 2.0
September 18, 2025 at 9:40 AM
all of that is in the pipeline for 2.0
Ricky's reaction to this was one of my favorites
bsky.app/profile/rick...
bsky.app/profile/rick...
September 18, 2025 at 2:08 AM
Ricky's reaction to this was one of my favorites
bsky.app/profile/rick...
bsky.app/profile/rick...
without a bundler, the "use server" will do nothing and the function will run on the client side instead of the server side. but with a bundler, it will allow you to directly interact with server side apis
September 18, 2025 at 1:45 AM
without a bundler, the "use server" will do nothing and the function will run on the client side instead of the server side. but with a bundler, it will allow you to directly interact with server side apis
both screenshots show client AND server code
solidstart uses "use server" compiler directive, svelte uses .remote.ts, both require bundler plugins to work.
this has nothing to do with SSR, this is making an RPC call to the server to fetch posts when the component is rendered on the client
solidstart uses "use server" compiler directive, svelte uses .remote.ts, both require bundler plugins to work.
this has nothing to do with SSR, this is making an RPC call to the server to fetch posts when the component is rendered on the client
September 18, 2025 at 1:43 AM
both screenshots show client AND server code
solidstart uses "use server" compiler directive, svelte uses .remote.ts, both require bundler plugins to work.
this has nothing to do with SSR, this is making an RPC call to the server to fetch posts when the component is rendered on the client
solidstart uses "use server" compiler directive, svelte uses .remote.ts, both require bundler plugins to work.
this has nothing to do with SSR, this is making an RPC call to the server to fetch posts when the component is rendered on the client
well and the "use server"
September 17, 2025 at 2:45 AM
well and the "use server"
Ryan beat me to it lol bsky.app/profile/ryan...
It is but there is a bit more nuance. We only tear at the leaves. I will explain it in the end. The thing is without any async consideration things do tear by default. If there was no Suspense if there was no Transition. If you go and load some data based on some other data it is tearing.
September 16, 2025 at 5:46 PM
Ryan beat me to it lol bsky.app/profile/ryan...
You can still opt in to 2 - hold previous consistent state. Just wrap the state update in a transition, and set some pending state to true. Since transitions in Solid 2.0 don't get entangled by default, you still have full control over the granularity of pending states.
September 16, 2025 at 5:45 PM
You can still opt in to 2 - hold previous consistent state. Just wrap the state update in a transition, and set some pending state to true. Since transitions in Solid 2.0 don't get entangled by default, you still have full control over the granularity of pending states.
Now even though the state tears, the user has a clear indication that something is happening in the background and it's expected to see old state. This also works with state that is derived from async sources, as well as multiple async sources. This provides more control than implicit grouping
September 16, 2025 at 5:45 PM
Now even though the state tears, the user has a clear indication that something is happening in the background and it's expected to see old state. This also works with state that is derived from async sources, as well as multiple async sources. This provides more control than implicit grouping
This also provides the developer full control over how and where to manage pending indicators.
If the above solid example was written with 2.0 primitives, you can very easily add a pending indicator using `isPending`, which can work with data that is async or derived from async sources.
If the above solid example was written with 2.0 primitives, you can very easily add a pending indicator using `isPending`, which can work with data that is async or derived from async sources.
September 16, 2025 at 5:45 PM
This also provides the developer full control over how and where to manage pending indicators.
If the above solid example was written with 2.0 primitives, you can very easily add a pending indicator using `isPending`, which can work with data that is async or derived from async sources.
If the above solid example was written with 2.0 primitives, you can very easily add a pending indicator using `isPending`, which can work with data that is async or derived from async sources.
While defaulting to 3 might seem like the default experience is broken or inconsistent, it's actually the most natural way of handling async updates. it's exactly how "fetch in useEffect" or non-suspense loading works. all state updates come in as they complete, no blocking or suspending by default.
September 16, 2025 at 5:45 PM
While defaulting to 3 might seem like the default experience is broken or inconsistent, it's actually the most natural way of handling async updates. it's exactly how "fetch in useEffect" or non-suspense loading works. all state updates come in as they complete, no blocking or suspending by default.
Defaulting to 2 is sensible because the existing content stays on screen. But when every state update is held until all async resolves, you might click a button, see nothing happening for a while, and think that something is broken. pending states also get lumped together quite often.
September 16, 2025 at 5:45 PM
Defaulting to 2 is sensible because the existing content stays on screen. But when every state update is held until all async resolves, you might click a button, see nothing happening for a while, and think that something is broken. pending states also get lumped together quite often.
Defaulting to 1 is very awkward because the moment you click a button or submit a form that causes refetching, huge chunks of content disappear from the screen. It's a very jarring experience, and the only way to show a pending indicator is by adding a useTransition hook that wraps every update.
September 16, 2025 at 5:45 PM
Defaulting to 1 is very awkward because the moment you click a button or submit a form that causes refetching, huge chunks of content disappear from the screen. It's a very jarring experience, and the only way to show a pending indicator is by adding a useTransition hook that wraps every update.
So none of this discussion is about "what UX are we building". In those terms all 3 are "broken" in my opinion.
This discussion is about the default behavior you get out of the framework, and how easy is it for the developer to opt in to a different behavior and/or a pending indicator.
This discussion is about the default behavior you get out of the framework, and how easy is it for the developer to opt in to a different behavior and/or a pending indicator.
September 16, 2025 at 5:45 PM
So none of this discussion is about "what UX are we building". In those terms all 3 are "broken" in my opinion.
This discussion is about the default behavior you get out of the framework, and how easy is it for the developer to opt in to a different behavior and/or a pending indicator.
This discussion is about the default behavior you get out of the framework, and how easy is it for the developer to opt in to a different behavior and/or a pending indicator.
React defaults to 1, Svelte defaults to 2, Solid defaults to 3.
To be honest, none of them are great options for the UX, which means ultimately it is the developer's responsibility to add pending indicators to let the user know something is happening or some data is out of date.
To be honest, none of them are great options for the UX, which means ultimately it is the developer's responsibility to add pending indicators to let the user know something is happening or some data is out of date.
September 16, 2025 at 5:45 PM
React defaults to 1, Svelte defaults to 2, Solid defaults to 3.
To be honest, none of them are great options for the UX, which means ultimately it is the developer's responsibility to add pending indicators to let the user know something is happening or some data is out of date.
To be honest, none of them are great options for the UX, which means ultimately it is the developer's responsibility to add pending indicators to let the user know something is happening or some data is out of date.
1 - Suspend, or don't show anything until the async completes and fall back to a suspense boundary.
2 - Hold, or keep the previous consistent state on the screen until the async completes.
3 - Tear, or show state updates as they come in on the UI.
2 - Hold, or keep the previous consistent state on the screen until the async completes.
3 - Tear, or show state updates as they come in on the UI.
September 16, 2025 at 5:45 PM
1 - Suspend, or don't show anything until the async completes and fall back to a suspense boundary.
2 - Hold, or keep the previous consistent state on the screen until the async completes.
3 - Tear, or show state updates as they come in on the UI.
2 - Hold, or keep the previous consistent state on the screen until the async completes.
3 - Tear, or show state updates as they come in on the UI.
I love that we have all three links here that show the three possible behaviors when there is pending async work on an existing UI component.
September 16, 2025 at 5:45 PM
I love that we have all three links here that show the three possible behaviors when there is pending async work on an existing UI component.
can you elaborate on "reverse the graph"?
i just see this
i just see this
September 10, 2025 at 10:17 PM
can you elaborate on "reverse the graph"?
i just see this
i just see this
now hit the retry button
September 10, 2025 at 10:10 PM
now hit the retry button
if you fetch in server components or relay fragments then you're fine, but useSuspenseQuery users are probably gonna be hit with this a whole lot more
September 10, 2025 at 9:57 PM
if you fetch in server components or relay fragments then you're fine, but useSuspenseQuery users are probably gonna be hit with this a whole lot more
i wonder if the perceived slowness is not just perceived but real slowness caused by suspense blocking component level data fetching
September 10, 2025 at 9:56 PM
i wonder if the perceived slowness is not just perceived but real slowness caused by suspense blocking component level data fetching
congrats on finally shipping this!
June 14, 2025 at 1:46 AM
congrats on finally shipping this!
if Meta's usage of React has led to certain heuristics being developed to prevent over-fetching, it makes sense that you'd want to offer those heuristics as a first class citizen within React, and you might also think that the broader ecosystem benefits from the same things.
June 13, 2025 at 2:44 AM
if Meta's usage of React has led to certain heuristics being developed to prevent over-fetching, it makes sense that you'd want to offer those heuristics as a first class citizen within React, and you might also think that the broader ecosystem benefits from the same things.