Utility functions for composing async `query()` results / `RemoteResource` objects
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- frontend
Research direction
Read the RemoteResource definition in packages/kit/types/index.d.ts and the query() documentation first. Compare the proposed Promise-like helpers with the supplied mergeRemoteResources example; done would require an agreed API and defined behavior for loading, ready, current, and error states.
Written by the indexing model from the issue text.
Description
Describe the problem
I've been enjoying the flexibility of SvelteKit Remote Functions' query() API and how I can choose to either await a reactive result or read reactive properties like .loading, .ready and .current directly. But as soon as I want the client side to orchestrate multiple query operations in series or in parallel and display all the intermediate states, I find myself wanting more flexible ways to compose the underlying RemoteResource objects together, while (for ergonomic templating reasons) adhering to the same RemoteResource shape.
Describe the proposed solution
I would like SvelteKit to provide the "progressively reactive" equivalents of Promise.then() / Promise.catch(), Promise.all() / Promise.allSettled(), Array#map() / Array#filter(), and Array#reduce() as built-in helper functions. These would optimally "$derive()" corresponding values and behaviors of .then / .loading / .ready / .current / .error from one or more existing RemoteResources, in turn returning one or more new RemoteResources.
Adding these would make one-to-one, one-to-many, many-to-many and many-to-one transformations of async resources easier, and consuming intermediate values more consistent, without sacrificing the fine-grained reactivity and templating ergonomics of async Svelte.
Alternatives considered
I initially tried composing my existing remote-side query() functions using plain Promise / async / await operations, but because there is no way to "stream" updates or return reactive objects, I have no way to expose intermediate states and can only have my UI update before and after the overall operation.
Importance
would make my life easier
Additional Information
Here's my attempt at a "reduce" utility function for RemoteResource:
import type { RemoteResource } from '@sveltejs/kit'
export const mergeRemoteResources = <
_ResourceValue,
_MergedResourceValue = _ResourceValue
>(
resources: RemoteResource<_ResourceValue>[],
merge: (
(
readyValues: _ResourceValue[],
resources?: RemoteResource<_ResourceValue>[]
) => _MergedResourceValue
)
): RemoteResource<_MergedResourceValue> => {
let readyValues = $derived(
resources
.filter(resource => resource.ready)
.map(resource => resource.current)
)
let overallValue = $derived(
merge(
readyValues,
resources
)
)
return Object.defineProperties(
(
Promise.race(resources)
.then(() => overallValue)
) as Promise<_MergedResourceValue>,
Object.getOwnPropertyDescriptors(new class {
current = overallValue
loading = $derived(
resources.some(query => query.loading)
)
ready = $derived(
resources.length > 0 && resources.every(query => query.ready)
)
error = $derived(
resources.find(query => query.error)?.error
)
})
) as RemoteResource<_MergedResourceValue>
}
This appears to work for simple cases, but it could probably be optimized / more aligned with Svelte's update cycle (judging by the memory leaks I'm apparently inducing from hot-module reloading).
- Dominant language
- JavaScript
- Stars
- 20.8k
- Forks
- 2.3k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 156
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sveltejs/kit
-
awaiting submitter
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
documentation pkg:adapter-vercel
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Similar issues
-
code-quality refactoring
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
github/gh-aw-firewall#8816 ·
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
langchain-ai/deepagents#6450 ·
-
optimization optimization:agents-md-curator
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
githubnext/gh-aw-cao#13143 ·
-
status: needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100