You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
createResource provides a convenient way to integrate asynchronous results in signals.
However, since createResource deals with asynchronous computations, it is easy to create signals within the createResource callback that will loose their owner and will fail with anything that calls useContext.
Currently, the workaround I found is to use getOwner and runWithOwner as follows:
retrack would call its continuation parameter with the owner at the createResource point of call.
The current type signature of createResource is already a bit complex, so it is not easy to add retrack in a very ergonomic way.
function createResource<T, U = true>(
fetcher: (
k: U,
- info: { value: T | undefined; refetching: boolean | unknown }+ info: { value: T | undefined; refetching: boolean | unknown, retrack: <A>(thunk: () => A) => A }
) => T | Promise<T>,
options?: ResourceOptions<T, U>
): ResourceReturn<T>
Since retrack is not part of the “info” of the resource, maybe it would be more appropriate to use a separate parameter, though…
Note that the situation is similar with lazy. The difference between lazy and createResource is that lazy returns a component whereas createResource returns a signal.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
createResource
provides a convenient way to integrate asynchronous results in signals.However, since
createResource
deals with asynchronous computations, it is easy to create signals within thecreateResource
callback that will loose their owner and will fail with anything that callsuseContext
.Currently, the workaround I found is to use
getOwner
andrunWithOwner
as follows:However, I wonder we could improve
createResource
to simplify that pattern. For instance, by adding a propertyretrack
to thefetcher
signature:retrack
would call its continuation parameter with the owner at thecreateResource
point of call.The current type signature of
createResource
is already a bit complex, so it is not easy to addretrack
in a very ergonomic way.Since
retrack
is not part of the “info” of the resource, maybe it would be more appropriate to use a separate parameter, though…Note that the situation is similar with
lazy
. The difference betweenlazy
andcreateResource
is thatlazy
returns a component whereascreateResource
returns a signal.Beta Was this translation helpful? Give feedback.
All reactions