use undefined instead of null for empty form prop

[ivanhofer]

Describe the problem

Using the new actions feature of SvelteKit, when loading the page the form prop is set to null. In my usecase I return an errors object if some of the form fields don't pass the validation in the action.

To not having to deal with unnecessary if checks or optional chainings, I'm setting errors to an empty object when the page loads and form is still null.

<script>
	export let form
	$: ({ errors } = form || { errors: { } }
</script>

{#if errors.email}
	invalid email address
{/if}

{#if form.errors.password} <!-- Uncaught TypeError: Cannot read properties of null (reading 'errors') -->
	please enter a stronger password
{/if}

This works fine, if I only use the errors object in that file. But if I accidentially access form again, I'll get an error because form is still null.

To not having the issue above I would need to set the default value like this:

<script>
	export let form
	$: form = form || { errors: { } }
</script>

But this requires me to write additional code.

Describe the proposed solution

form should be undefined and not null to make it possible to set a fallback value like you would do in other Svelte components:

<script>
	export let form = { errors: { } }
	$: ({ errors } = form
</script>

{#if errors.email}
	invalid email address
{/if}

{#if form.errors.password} <!-- no error! -->
	please enter a stronger password
{/if}

Alternatives considered

Leave it as it is.

Importance

would make my life easier

Additional Information

No response

[dummdidumm]

I just tested this in the Svelte REPL, changing this to undefined wouldn't make any difference. The Svelte logic is to use the fallback value only initially, so once you set it to undefined it gets undefined. I believe there's an issue in the Svelte repo about this, but I can't find it right now.
Question is, if we want to implement this, if we do it before 1.0 so once the Svelte behavior is changed (which would be in 4.0 because it's a breaking change) we can profit from it without changing SvelteKit code.

[Tal500]

You may use the relatively new JS/TS language feature "?":
form?.errors?.blabla

Every "?.*" junction will return undefined if the l.h.s. is undefined or null, and the original value otherwise.

[ivanhofer]

I just tested this in the Svelte REPL, changing this to undefined wouldn't make any difference. The Svelte logic is to use the fallback value only initially, so once you set it to undefined it gets undefined. I believe there's an issue in the Svelte repo about this, but I can't find it right now. Question is, if we want to implement this, if we do it before 1.0 so once the Svelte behavior is changed (which would be in 4.0 because it's a breaking change) we can profit from it without changing SvelteKit code.

Ah right, it will only set the default value on the first time. In my case I always return the same shape for error objects, so it will always be defined once I have submitted the form and the form prop gets updated. So changing it from null to undefined would support my specific use case.

For now I will continue using this approach:

<script>
	export let form
	$: form = form || { errors: { } }
</script>

Can you please link me to the Svelte issue describing the behaviour you are referring to?

[dummdidumm]

Haven't found it so far, maybe the almighty @Conduitry knows, I believe he commented on that issue

[dummdidumm]

Moving this to post-1.0 (in other words, for consideration for 2.0). It's unclear by now if the behavior will be changed for Svelte 4 (although I would be in favor of it), and if it is, it would probably result in a hard-to-catch subtle change in behavior if it's possible to use SvelteKit 1.0 with Svelte 4.

[Conduitry]

@dummdidumm Sorry, missed your comment from a few weeks ago. This was discussed in sveltejs/svelte#4442 and sveltejs/svelte#5673 but both of these are closed. I don't know that there is an open issue tracking this, and I'm not convinced that this is something we'd want to change anyway, even as a breaking change in Svelte 4.

[Conduitry]

This behavior was also made explicit in the documentation, I'm now remembering, in sveltejs/svelte#4460.

[ivanhofer]

I think this conversation is moving in a different direction.

My initial suggestion was to just use undefined instead of null to be able to set an initial default value when the page loads. With undefined we could use the same concept as for regular Svelte components.
Once a form gets submitted the developer is responsible for returning a useful value or to handle cases where nothing gets returned.

[dummdidumm]

I'm not sure the change is worth it if we don't change the behavior in Svelte 5 for the fallback being applied everytime the value is undefined, not just the first time. Furthermore, there's now a change in Svelte 5 which disallows changing the props of the parent if they weren't passed with bind:, and also disallows fallback values for bind: properties. This would make this pattern impossible to apply, since either the generated Root.svelte in SvelteKit passed the form with bind: to signal "yeah you can change this" and that means you can't have default values set, or we don't adjust the generated Root.svelte but that means that people can no longer manipulate properties on the form object. The latter seems like the worse option, and as such I think keeping this as null is ultimately better because it forces you to set the fallback value in a different way right away, satisfying the new rules.

[benmccann]

I think we should punt on this until Svelte 5 is a bit more settled. We can revisit and make a final decision then. I'll move this to the 3.0 milestone for now