some properties in type of object returned from ActionData is missing

[harrylaulau]

Describe the bug

This issue is quite hard to explain by words, I would try my best to describe it precisely. But it think it would be the best to look at the screenshots / code below or the repo.

Issue:
When the invalid function is used as a return of multiple conditionals, AND if they share properties of the same type, the other properties that they don't share would be missing. It is even stranger when an object is the value of the property.

+page.server.ts

import { invalid, redirect } from '@sveltejs/kit';
import type { Actions } from './$types';
export const actions: Actions = {
	default: async ({ request, url }) => {
		if (url.searchParams.get('v') === '0') return invalid(400, { first: '1' });
		if (url.searchParams.get('v') === '1') return invalid(400, { first: 1, second: 'second' });
		if (url.searchParams.get('v') === '2') return invalid(400, { first: '3', second: 'second' });
		if (url.searchParams.get('v') === '3') return invalid(400, { first: {}, second: 'second' });
		if (url.searchParams.get('v') === '4') return { third: 3 };
		if (url.searchParams.get('v') === '5') return { third: 'third' };
		if (url.searchParams.get('v') === '6') return { fourth: 'fourth' };
	}
};

+page.svelte

<script lang="ts">
	import type { ActionData } from './$types';
	export let form: ActionData;
	$: console.log(form ?? 'undefined');
</script>

{#each [0, 1, 2, 3, 4, 5, 6] as x}
	<div>
		<a href={'/?v=' + x}>to {x}</a>
	</div>
{/each}
<form method="POST">
	<button>print action output</button>
</form>

Reproduction

https://github.com/harrylaulau/sveltekittest

Logs

No response

System Info

System:
    OS: macOS 12.6
    CPU: (10) arm64 Apple M1 Max
    Memory: 324.70 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.15.0 - ~/.nvm/versions/node/v16.15.0/bin/node
    Yarn: 1.22.19 - ~/Library/pnpm/yarn
    npm: 8.12.1 - ~/.nvm/versions/node/v16.15.0/bin/npm
    Watchman: 2022.08.15.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 105.0.5195.125
    Safari: 16.0
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.74 
    @sveltejs/kit: next => 1.0.0-next.483 
    svelte: ^3.44.0 => 3.50.1 
    vite: ^3.1.0 => 3.1.0

Severity

serious, but I can work around it

Additional Information

It seems to me that the bug occurs from the return type of default.

+page.server.ts

proxy+page.server.ts

[dummdidumm]

Could you clarify if this is a typing issue (the types are incorrect) or a runtime issue (something isn't showing up in export let form as you would expect)?

[harrylaulau]

Could you clarify if this is a typing issue (the types are incorrect) or a runtime issue (something isn't showing up in export let form as you would expect)?

This is a typing issue

[williamviktorsson]

I am experiencing the same.

I would much more prefer having the ActionData type to be:

type ActionData = {
    first: string | undefined,
    second: string | undefined,
    third: string | undefined,
    fourth: string |undefined
}

[aloker]

I am experiencing the same.

I would much more prefer having the ActionData type to be:

type ActionData = {
    first: string | undefined,
    second: string | undefined,
    third: string | undefined,
    fourth: string |undefined
}

I very much prefer the unions as they are now. While the auto generated types are useful, you'll have a way better experience if you add a little bit of typing yourself. E.g., you could type the payload of invalid responses as { status: "invalid"; } & Model & { errors: { [k in keyof Model]?: string}} and valid responses as { status: "ok"; } & Model or so. Than you can use status as a discriminator for type narrowing and you'll have nice typing on the page. I'd you have more actions, add another discriminator (e.g. action) and you can handle pretty much any situation smoothly.

[harrylaulau]

My current use case:

type ActionData = 
| { target: 'email', message: 'incorrect format'}
| { target: 'email', message: 'not exist'}
| { target: 'trials', message: 'requested too many times', remaining: '30'} // indicating needed to wait 30 seconds to try again

But with current sveltekit version, the remaining property is missing.

So I suspect it is a bug as it 'eats up' some types. And that occurs at the return type of the default.

I do like the idea of discriminative union as it would be handled beautifully as we use it with conditionals.

[williamviktorsson]

I am experiencing the same.
I would much more prefer having the ActionData type to be:

type ActionData = {
    first: string | undefined,
    second: string | undefined,
    third: string | undefined,
    fourth: string |undefined
}

I very much prefer the unions as they are now. While the auto generated types are useful, you'll have a way better experience if you add a little bit of typing yourself. E.g., you could type the payload of invalid responses as { status: "invalid"; } & Model & { errors: { [k in keyof Model]?: string}} and valid responses as { status: "ok"; } & Model or so. Than you can use status as a discriminator for type narrowing and you'll have nice typing on the page. I'd you have more actions, add another discriminator (e.g. action) and you can handle pretty much any situation smoothly.

Would you happen to have an example of how to use the unions as they are now?

The example from the docs will not pass typing checks when the unions are the way they are.

https://kit.svelte.dev/docs/form-actions#anatomy-of-an-action-validation-errors

Attached below the errors from running the docs example.

[harrylaulau]

I am experiencing the same.
I would much more prefer having the ActionData type to be:

type ActionData = {
    first: string | undefined,
    second: string | undefined,
    third: string | undefined,
    fourth: string |undefined
}

I very much prefer the unions as they are now. While the auto generated types are useful, you'll have a way better experience if you add a little bit of typing yourself. E.g., you could type the payload of invalid responses as { status: "invalid"; } & Model & { errors: { [k in keyof Model]?: string}} and valid responses as { status: "ok"; } & Model or so. Than you can use status as a discriminator for type narrowing and you'll have nice typing on the page. I'd you have more actions, add another discriminator (e.g. action) and you can handle pretty much any situation smoothly.

Would you happen to have an example of how to use the unions as they are now?

The example from the docs will not pass typing checks when the unions are the way they are.

https://kit.svelte.dev/docs/form-actions#anatomy-of-an-action-validation-errors

Attached below the errors from running the docs example.

I think this should have worked. They aren’t working only because maybe there is a bug.

[david-plugge]

Here is a workaround i got from https://fettblog.eu/typescript-union-to-intersection/

src/lib/types.ts

export type UnionToIntersection<T> = (T extends any ? (x: T) => any : never) extends (x: infer R) => any
		? R
		: never;

src/routes/+page.svelte

<script lang="ts">
	import type { ActionData } from './$types';
	import type { UnionToIntersection } from '$lib/types';

	export let form: UnionToIntersection<ActionData>;
</script>

[williamviktorsson]

It would seem that PageData types are handling this correctly when data of different types could be passed.

[TheRealUnicorns]

Types aren't missing. ActionData is an union so you'll need to typeguard

type ActionData = 
| { target: 'email', message: 'incorrect format'}
| { target: 'email', message: 'not exist'}
| { target: 'trials', message: 'requested too many times', remaining: '30'};

function action(): ActionData | undefined {
    return { target: 'trials', message: 'requested too many times', remaining: '30' };
}

const form = action();
console.log(form?.target, form?.message); // This works as they're common in all types of union
// console.log(form?.remaining); // This will throw an error.
if (form?.target == 'trials') {
    // This works.
    console.log(form.remaining);
}

The docs don't use typeguards so it throws type errors as well.
this (not typesafe but works)

{#if form?.missing}<p class="error">No user found with this email</p>{/if}

vs (is typesafe but verbose)

#{if form && 'missing' in form && form.missing}....

[harrylaulau]

Types aren't missing. ActionData is an union so you'll need to typeguard

type ActionData = 
| { target: 'email', message: 'incorrect format'}
| { target: 'email', message: 'not exist'}
| { target: 'trials', message: 'requested too many times', remaining: '30'};

function action(): ActionData | undefined {
    return { target: 'trials', message: 'requested too many times', remaining: '30' };
}

const form = action();
console.log(form?.target, form?.message); // This works as they're common in all types of union
// console.log(form?.remaining); // This will throw an error.
if (form?.target == 'trials') {
    // This works.
    console.log(form.remaining);
}

The docs don't use typeguards so it throws type errors as well. this (not typesafe but works)

{#if form?.missing}<p class="error">No user found with this email</p>{/if}

vs (is typesafe but verbose)

#{if form && 'missing' in form && form.missing}....

But how would it work in the action in +page.server.ts ?

[williamviktorsson]

I've tried to make a better example to highlight the issue.

If I have a form Action with this code:

if (condition)
	return { message: "123", info: "abc" }
else
	return { message: "123", something: 123 }

I get the following type (correct):

(alias) type ActionData = {
    message: string;
    info: string;
    something?: undefined;
} | {
    message: string;
    something: number;
    info?: undefined;
}

But using the invalid helper function:

if (condition)
	return invalid(400,{ message: "123", info: "abc" })
else
	return invalid(400,{ message: "123", something: 123 })

I get this type which is harder to work with and inconsistent with how the load function return types are generated as well:

(alias) type ActionData = {
    message: string;
    info: string;
} | {
    message: string;
    something: number;
}

Are there perks to this or is it a bug?

In the case where it's intended, would it be easy to opt out of it by let's say not using the invalid helper function?

[harrylaulau]

I've tried to make a better example to highlight the issue.

If I have a form Action with this code:

if (condition)
	return { message: "123", info: "abc" }
else
	return { message: "123", something: 123 }

I get the following type (correct):

(alias) type ActionData = {
    message: string;
    info: string;
    something?: undefined;
} | {
    message: string;
    something: number;
    info?: undefined;
}

But using the invalid helper function:

if (condition)
	return invalid(400,{ message: "123", info: "abc" })
else
	return invalid(400,{ message: "123", something: 123 })

I get this type which is harder to work with and inconsistent with how the load function return types are generated as well:

(alias) type ActionData = {
    message: string;
    info: string;
} | {
    message: string;
    something: number;
}

Are there perks to this or is it a bug?

In the case where it's intended, would it be easy to opt out of it by let's say not using the invalid helper function?

As you said the invalid is a helper function and you may opt out of it. The reason to use it is to differentiate from successful submit or invalid submit thus better dev experience. For the typings, both cases are not bug as they are computed by typescript. The bug I am illustrating in the issue is instead a property being missing completely from the generated ActionData type. You may clone the repo I posted and try to see the type with vscode.

[williamviktorsson]

@harrylaulau

I cloned your repo and had a look and I realize we are trying to highlight two separate issues. Your issue is that some potential return types are missing entirely in the generated types description.

My issue is that the algorithm for generating return types behaves differently on objects returned using the invalid helper function, compared to successfully returned objects.

I am now certain these are related issues

I cloned your repo and if I do this instead:

if (url.searchParams.get('v') === '0') return { first: '1' };
if (url.searchParams.get('v') === '1') return  { first: 1, second: 'second' };
if (url.searchParams.get('v') === '2') return  { first: '3', second: 'second' };
if (url.searchParams.get('v') === '3') return { first: {}, second: 'second' };
if (url.searchParams.get('v') === '4') return  { third: 3 };
if (url.searchParams.get('v') === '5') return  { third: 'third' };
if (url.searchParams.get('v') === '6') return { fourth: 'fourth' };

The types are properly generated.

If I do this:

if (url.searchParams.get('v') === '0') return invalid(400, { first: '1' });
if (url.searchParams.get('v') === '1') return invalid(400, { first: 1, second: 'second' });
if (url.searchParams.get('v') === '2') return invalid(400, { first: '3', second: 'second' });
if (url.searchParams.get('v') === '3') return invalid(400, { first: {}, second: 'second' });
if (url.searchParams.get('v') === '4') return invalid(400, { third: 3 });
if (url.searchParams.get('v') === '5') return invalid(400, { third: 'third' });
if (url.searchParams.get('v') === '6') return invalid(400, { fourth: 'fourth' });

They are not .

I believe the issue you are seeing when mixing both successful and invalid errors are due to the invalid errors not being handled properly. If types were generated for the invalid returns in the same matter the regular return objects have their types returned, both of our issues would be resolved.