Abort signals for remote functions

[mihaipoenaru]

Describe the problem

As I understand it, when a remote function fires on the client, it's actually a fetch wrapper. I have a case where I have to call a remote whenever an input changes to search for something, as the user types. Now this is an obvious race condition, depending on how flaky the network decides to be, so I need to cancel a request as soon as the user changes the input, so that old requests don't mess up my result section.

Now I could just make a REST api and just manually fetch it, making it possible to use abort signals, but surely there should be some way for a remote function to be able to receive an abort signal. I've tried to search in the docs, but I couldn't find a way to do it, at least not an obvious one.

Describe the proposed solution

The most straightforward way is to have a config object that would contain some options for the underlying fetch call, one of which would be the abort signal. Otherwise make the remote functions abortable directly, somehow

Alternatives considered

Like I said, a classic api with a manual fetch in sveltekit, but now that we have remote function, they should technically replace all that nonsense.

Importance

nice to have

Additional Information

No response

[ollema]

have you read about getAbortSignal?

edit: maybe that does not solve what you are looking for here, just wanted to make sure you have seen that part of the docs

[mihaipoenaru]

@ollema yes but I'm not sure how that's supposed to help my case at all. My issue is not that I can't get an abort signal, but that I can't abort the actual remote function, as it has no way to receive signals. It can't serialize those to send them to the server so that I can forward them to the fetch I'm doing to the external API.

Unless I'm missing something obvious...

[dummdidumm]

Under the hood we implemented logic to not have stale requests overwrite later results, but that does not apply in your case because your query is different each time (because the args change).

Could you show a code snippet to better understand your use case?

[mihaipoenaru]

Certainly @dummdidumm. This is my entire component, that scearches for a city name (first in a cache, then in the API)

<script lang="ts">
	import SearchableSelect, {
		type SearchableSelectProps
	} from '$lib/ui/components/form/inputs/SearchableSelect.svelte';
	import { searchCity, searchCityCache } from '$lib/remotes/geoapify.remote';

	let { value = $bindable() }: { value?: string | number } = $props();

	let inputQuery: string = $state('');
	let searching = $state(false);
	let options: SearchableSelectProps['options'] = $state.raw([]);
	const minChars = 3;

	$effect(() => {
		if (inputQuery.length >= minChars) updateOptions(inputQuery);
	});

	async function updateOptions(query: string) {
		const cache = await searchCityCache(query);
		if (cache.length > 0) {
			options = cache.map((c) => ({ label: `${c.city}, ${c.country}`, value: c.cacheId }));
			return;
		}

		options = [];
		searching = true;

		const apiResult = await searchCity(query);
		options = apiResult.map((r) => ({
			label: `${r.city}, ${r.country}`,
			value: `${r.city}, ${r.country}`
		}));
		searching = false;
	}
</script>

<SearchableSelect
	class="w-70"
	{minChars}
	{options}
	bind:query={inputQuery}
	bind:value
	showLoadingSpinner={searching}
/>

This is the RF

export const searchCity = query(
	z.string(),
	async (query) => {
		const res = await findCities(query);
		if (res.errorMessage) throw new Error(res.errorMessage);

		return res.data.map((d) => ({
			city: d.city,
			country: d.country
		}));
	}
);

//another file

export async function findCities(query: string): Promise<ApiResult<SearchResult[]>> {
	const { fetch } = getRequestEvent();
	const response = await fetch(
		`${geoapifyRoot}?text=${query}&limit=100&type=city&lang=ro&apiKey=${serverSettings.geoapify.apiKey}`
	);

	if (!response.ok) return { data: [], errorMessage: `Geoapify API error: ${response.status}` };
	const gResp = (await response.json()) as AutocompleteResponse;

	return {
		data: gResp.features.map((f) => ({
			city: f.properties.city,
			country: f.properties.country,
			countryCode: f.properties.countryCode,
			rank: f.properties.rank.confidence
		}))
	};
}

[dummdidumm]

Thanks for the code!

In your case I'm not really sure if an abort signal would give us much since you're actually calling two queries back to back. I think you're better off implementing your own abort signal logic, for example using a token and checking if it's still current:

<script lang="ts">
	import SearchableSelect, {
		type SearchableSelectProps
	} from '$lib/ui/components/form/inputs/SearchableSelect.svelte';
	import { searchCity, searchCityCache } from '$lib/remotes/geoapify.remote';

	let { value = $bindable() }: { value?: string | number } = $props();

	let inputQuery: string = $state('');
	let searching = $state(false);
	let options: SearchableSelectProps['options'] = $state.raw([]);
	const minChars = 3;
+	let token = {};

	$effect(() => {
		if (inputQuery.length >= minChars) updateOptions(inputQuery);
	});

	async function updateOptions(query: string) {
+		const t = token = {};
		const cache = await searchCityCache(query);
+		if (t !== token) return;
		if (cache.length > 0) {
			options = cache.map((c) => ({ label: `${c.city}, ${c.country}`, value: c.cacheId }));
			return;
		}

		options = [];
		searching = true;

		const apiResult = await searchCity(query);
+		if (t !== token) return;
		options = apiResult.map((r) => ({
			label: `${r.city}, ${r.country}`,
			value: `${r.city}, ${r.country}`
		}));
		searching = false;
	}
</script>

<SearchableSelect
	class="w-70"
	{minChars}
	{options}
	bind:query={inputQuery}
	bind:value
	showLoadingSpinner={searching}
/>

Or you leverage async Svelte more to your advantage, and instead of using an effect to kick up the request, you're using async derived (for the fetches) and $effect.pending() (for the loading spinner)

<script lang="ts">
	import SearchableSelect, {
		type SearchableSelectProps
	} from '$lib/ui/components/form/inputs/SearchableSelect.svelte';
	import { searchCity, searchCityCache } from '$lib/remotes/geoapify.remote';

	let { value = $bindable() }: { value?: string | number } = $props();

	let inputQuery: string = $state('');
	let searching = $state(false);
	let options: SearchableSelectProps['options'] = $state.raw([]);
	const minChars = 3;

	async function updateOptions(query: string) {
		const cache = await searchCityCache(query);
		if (cache.length > 0) {
			return cache.map((c) => ({ label: `${c.city}, ${c.country}`, value: c.cacheId }));
		}

		const apiResult = await searchCity(query);
		return apiResult.map((r) => ({
			label: `${r.city}, ${r.country}`,
			value: `${r.city}, ${r.country}`
		}));
	}

	const options = $derived(inputQuery.length < minChars ? [] : await updateOptions(inputQuery));
</script>

<SearchableSelect
	class="w-70"
	{minChars}
	{options}
	bind:query={inputQuery}
	bind:value
	showLoadingSpinner={$effect.pending()}
/>

{#each options as option}
   ...
{/each}

...or are you purposefully not doing that, and if so, why?

[mihaipoenaru]

No reason not to do that. I was prototyping something similar, but it just felt too "hacky" to do it like the first option. Not too familiar with effect.pending, but I'll check it out. I mostly thought of it like a regular fetch, so I thought it would make sense, or be more elegant to treat it as such.

I am confused about one thing, why does it matter if there's queries back to back? Is it something under the hood that makes it not possible? I could just give the same abort signal to both of them.

[dummdidumm]

I mostly thought of it like a regular fetch, so I thought it would make sense, or be more elegant to treat it as such.

You could elaborate on that? Regardless of whether it's a "regular fetch" or a "remote function fetch" you're encouraged to leverage Svelte's new async features (i.e. await in $derived/the template, $effect.pending() etc).

I am confused about one thing, why does it matter if there's queries back to back? Is it something under the hood that makes it not possible? I could just give the same abort signal to both of them.

I guess you're right, you could do that.

Given that there's two alternative ways to solve it - do you still feel strongly about this being added?

[mihaipoenaru]

You could elaborate on that? Regardless of whether it's a "regular fetch" or a "remote function fetch" you're encouraged to leverage Svelte's new async features (i.e. await in $derived/the template, $effect.pending() etc).

Yeah, as I said, I was not familiar with pending, so I wasn't sure how to use $derived in that case, but that's cleared up now.

Given that there's two alternative ways to solve it - do you still feel strongly about this being added?

Well, I never felt too strongly to begin with, that's why I put in "nice to have", because (and this is strictly a matter of opinion) it does feel "nicer" and more straightforward (to me at least) to abort an operation, rather than using $effect.pending. If I'm the only one that ran into this issue and wanted to solve it with aborts, I guess it's probably not effort well spent to work on this.

[dummdidumm]

because it does feel "nicer" and more straightforward (to me at least) to abort an operation, rather than using $effect.pending.

Sorry for the continued clarification questions (and thank you for answering all the others!) - but could you elaborate a bit on this? What makes using $effect.pending() "not as nice" to use? Is it the name? Is it that it feels too indirect? Just unfamiliar? Something else?

[mihaipoenaru]

Well, I try to avoid effects in general, because it says in the docs not to abuse them, since they're more of an escape hatch. I do still use them a lot, but only when I have to because I'm trying not to form a habit, or when using them will definitely make the code cleaner.

In this particular case, I kind of have to use it, and from this discussion I can either use the plain ol' $effect and improvise a solution, or use the $effect.pending, which I feel is a very indirect way to do this particular task. It's not that it's bad, just that my ranking would be:

1. Use effect and have a fetch/remote function that I can just cancel
2. Use $effect and sprinkle in some extra code to coax it into giving me the latest result
3. Use $effect.pending which not only I'm not familiar with (even after 3 projects of medium size with svelte, I never needed to use it), but also feels like it's too indirect, like it's svelte getting in the way of things instead of making it easier.

But to reiterate, this is basically a nitpick, it's not like it's affecting my enjoyment of svelte or anything.