Clarification on createAsync and Suspense behavior
i have an async data which relies on params
id and offset.
id is the slug of the page (location.params.id) while offset is just a signal.
the async data is wrapped by a Suspense component with a fallback.
when offset is updated, everything inside the Suspense is re-rendered and a fallback is shown.
however, when id changes when navigating, it doesn't seem to re-render - parts of the component are surgically updated - and it doesn't display a fallback.
i'm wondering why is there a difference in behavior in the two? i've always thought that updating a prop that createAsync depends on doesn't cause a re-render - like you have to deliberately do a <Show when={prop} keyed /> to force a re-render
is this because navigation uses a transition? if so, can i employ the same strategy when changing offset?
i've tried with with createAsync and createAsyncStore and both exhibit the same behavior. to avoid triggering Suspense or having a Suspense, am i better off using createResource instead?20 Replies
Yeah this is because
id is modified within a transition, so the Suspense shows its previous data instead of the fallback. You can wrap the update to offset in startTransition and the same thing should happenokay cool, i'll try to do that 🫡 thanks for the fast response!!!
check this
https://discord.com/channels/722131463138705510/910635844119982080/1354176737071599717
this seem to be a common issue, without a proper solution yet, as
createAsync design is not finalized.
you better off use the createResource and if you plan to upgrade to 2.0, you can only hope that it will still exists.
also it seem that you want the opposite of what I just linked tohowever, when id changes when navigating,
FYI: querys automatically start transitions for navigations and revalidations. (And any action will revalidate all active querys unless it supplies a restricted list).You didn't pursue Ryan's first suggestion of using a signal for a local transition; it turns out to be a pretty benign workaround.
So proclaiming “don't use
createAsync(); it's not yet finalized” is unnecessarily alarmist.I might have missed the suggestion, what is the signal solution mean?
i think the problem with the original issue, was that the createAsync changes after the input params changes which is mostly too late becuase it is already in a transition.
I stand by my ALARM, don't use createAsync until it is finalized.
becuase it is clearly not finalized as stated by ryan
ok, not don't use it, just be aware of its status
honesty is the best policy
Use your own Transition and write to local state and write back to the search params. By awaiting the transition you can set your own isPending Signal on either side and show appropriate UI. This is how isRouting in the router works.The code I just included above is my attempt at following this advice.
ok, if i follow this correctly,instead of depending on the searchParams you manually set the signal so it can be handled before it goes into transition?
because it is clearly not finalized as stated by ryanHe's also similarly implied that certain
createResource features were probably a mistake and that it is unfortunate that people are relying on them in situations were other means or approaches would be more appropriate.sure thing, the problem is that once you release something you mostly can't take it back.
that is why I think people who are ok with 1.x should keep using the createResource
if they plan to go to 2.x they will need a migration plan, which solid will have to support if it compleltly breaks older apps
before and if things are to be removed, there will need to be some community feedback gathered
but it might be too soon for that is 2.x design is still on going
other means or approaches would be more appropriate.this is more about education, I don't see a problem with the feature, but if there is a better way this way should be promoted, while allowing the escape hatches to exists for advance use cases. for instance, why I can't know when I am in transition or when a transition is done? the abstraction in some cases are limiting with createResource you mostly don't have those limits
that is why I think people who are ok with 1.x should keep using the createResource
Engineering is about solving problems within a set of given constraints. createAsync() may happen to be more constrained than createResource but that is more than compensated for by the combined features you get with querys and actions.
By encouraging people to stick with createResource you are preventing them from taking advantage of query and action and more to the point making the inevitable transition to 2.x more difficult as they have had more time to habituate to the perhaps sub-optimal createResource usage patterns.I am not favouring either, just use which ever works best for you
https://docs.solidjs.com/reference/basic-reactivity/create-resource
until the docs are not saying warning about using this, I think it is fair to recommend using it
createResource - SolidDocs
Documentation for SolidJS, the signals-powered UI framework
but anyway, I will take you opinion under consideration
The warnings are there:
However, usingThe documentation team is faced with the continued challenge of having to present feature focused documentation that is expected by the general developer audience when in fact education is really about how all these primitives are meant to compose.querydirectly increateResourcewill not work since the fetcher is not reactive and will not invalidate properly.
I need explicit yellow warning saying this is going to be deprecated and is not recommended otherwise these words mean nothing to me because i don't know what
query is , and if it applies to me.query - SolidDocs
Documentation for SolidJS, the signals-powered UI framework
thanks, now I will need to understand why createResource is not good for caching
query is not a cache-it de-duplicates requests, i.e. reuses response payloads.yes, I understand query is actually a memoization
but I need to understand the relation as to why createResource does not work with it
Because without the drastic action that
createAsync() has to take right now to make createResource() work, querys would have no way of driving all the dependent resource accessors upon revalidation.