🦋 Changeset detected

Latest commit: d8d02bc

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Preview: https://svelte-dev-git-preview-kit-14272-svelte.vercel.app/

Shouldn't this be the default behavior of query rather than a new type of remote function?

Comparing this upcoming feature with what tRPC has, it appears that this PR is equivalent to their httpBatchLink; however, tRPC also has httpBatchStreamLink for the following purpose/use-case:

When batching requests together, the behavior of a regular httpBatchLink is to wait for all requests to finish before sending the response. If you want to send responses as soon as they are ready, you can use httpBatchStreamLink instead. This is useful for long-running requests.

Will/Does SvelteKit have a similar functionality incorporated into query.batch, or perhaps via a similar equivalent remote function query.streamBatch?

Shouldn't this be the default behavior of query rather than a new type of remote function?

At an API level, no — it would be very weird and annoying if I always had to deal with arrays, when most queries are singular. I think what you're asking though is whether we should batch all simultaneous queries into a single request.

We've talked about this a lot, and we've been careful to leave enough design space for us to switch to a batched implementation if it seems like the right approach. So far we've decided against it though, partly because it's a heck of a lot simpler as-is (make it work, make it right, then make it fast), partly because it would likely constrain our options when it comes to caching, when we get round to that.

Will/Does SvelteKit have a similar functionality incorporated into query.batch

No. There's no point. The use case for query.batch is that you have a bunch of IDs and want to get the corresponding objects for those IDs in a single external API call or database query. In that scenario you'll get all the data back at once, so there's nothing to be gained by streaming them back.

If we were to offer something that is like httpBatchLink (which IIUC is about coalescing queries of different types into a single request, rather than turning queries of the same type into a single database call) then yes, the results would be individually streamed. You wouldn't have to configure anything though, it would just be How It Worked. See above for why we may not do that though.

Separately, there will be a primitive for streaming: #14292

I think what you're asking though is whether we should batch all simultaneous queries into a single request

Yes, that's what I thought this new remote function would do
But after reading the PR examples a little more, I better understood what it actually does, but not what it's for

I mean, I understood that the intention is for the front-end part that only cares about one piece of data to use the query that fetches only that piece of data, but without causing multiple calls if you have to fetch several similar pieces

But I feel like in 90% of cases, you won't know in advance which pieces of a list to fetch, so an aggregate call will be necessary anyway, especially if it involves things like pagination and filters

But even when that's not the case, I feel like a much simpler solution would be the ability to add an item to the cache that hasn't been requested yet

Here's a snippet of actual code from a React + Tanstack query app
that I'm currently converting to Svelte

export const usersOptions = ({
	page = 1,
	size = 10,
	email,
	name,
}: NonNullable<UsersRequest["params"]>["query"] = {}) =>
	queryOptions({
		queryKey: ["users", page, size, email, name],
		queryFn: ({ signal }) =>
			apiClient.get["/v1/users"]({
				params: {
					query: {
						page,
						size,
						sort: "name,ASC",
						...(email && { email }),
						...(name && { name }),
					},
				},
				signal,
			}),
	});

export const userOptions = (id: string) =>
	queryOptions({
		queryKey: ["user", id],
		queryFn: ({ signal }) =>
			apiClient.get["/v1/users/{id}"]({
				params: { path: { id } },
				signal,
			}),
	});

export const useUsers = ({
	page = 1,
	size = 10,
	email,
	name,
	sort = "name,ASC",
}: NonNullable<UsersRequest["params"]>["query"] = {}) => {
	const queryClient = useQueryClient();
	const query = useSuspenseQuery(
		usersOptions({ page, size, email, name, sort }),
	);
	query.data.content?.forEach(user => {
		queryClient.setQueryData(userOptions(user.id ?? "").queryKey, user);
	});
	return query;
};

export const useUser = (id: string) => useSuspenseQuery(userOptions(id));

So when I render, for example, a table of users, the table uses the hook that fetches the list, but the rows render the data from the hook that fetches the individual item

But the request for the individual items never happens, because their values ​​have already been cached by the hook that fetches the list

Currently if you try to add an item that has not yet been requested in the cache, the request is made