feat: allow serialization/deserialization of custom data types

[trueadm]

Enables serialization and deserialization of custom data types in the form of hooks.

Closes #9401.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 66e6b2e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[Rich-Harris]

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

this is an automated message

[dominikg]

I'd love an api where serialize and deserialize implementations for a custom type are in the same file.

They have a strict relation to one another and changing one without the other can lead to bugs. It would also simplify implementing tests that ensure serialize(deserialize(x)) equals x and deserialize(serialize(y)) equals y

Users can possibly do that in userland by importing them from such a file, but just lik param matchers i think we could provide that from a known location.

[trueadm]

I'd love an api where serialize and deserialize implementations for a custom type are in the same file.

They have a strict relation to one another and changing one without the other can lead to bugs. It would also simplify implementing tests that ensure serialize(deserialize(x)) equals x and deserialize(serialize(y)) equals y

Users can possibly do that in userland by importing them from such a file, but just lik param matchers i think we could provide that from a known location.

So I tried to do something like that, but I gave up. I couldn't figure out how how we could safely take the function on the server and use it on the client, given the function references imports, and generate client code with the same logic without leaking server stuff. This is my first Kit PR, so maybe I just need someone to help me understand how that sort of thing can be done.

[dominikg]

its a pair of pure functions tied together by a name, so shouldn't it work in a similar way as matchers?
maybe 3 functions if you want to add a test function too

//src/serializers/foo.js
export const is(foo: any): boolean;
export const serialize(foo: Foo): string;
export const deserialize(str: string): Foo;

due to treeshaking only one of serialize and deserialize should make it to the output of client or server.

[trueadm]

its a pair of pure functions tied together by a name, so shouldn't it work in a similar way as matchers? maybe 3 functions if you want to add a test function too

//src/serializers/foo.js
export const is(foo: any): boolean;
export const serialize(foo: Foo): string;
export const deserialize(str: string): Foo;

due to treeshaking only one of serialize and deserialize should make it to the output of client or server.

The body of the functions will require importing the class though. So when it runs on the client, the import will be missing?

[dummdidumm]

I'd love an api where serialize and deserialize implementations for a custom type are in the same file.

It's not done like that because currently we're not using the serialize function on the client / the deserialize function on the server.

[dummdidumm]

Looks good so far! I think this doesn't handle the client side navigation case yet though, i.e. when the data loading happens via __data.json. E.g. if you start on /foo and that contains a link to /serialization-basic, so it (de)serialize the data correctly?

[dummdidumm]

was is necessary after all due to the dynamic imports? If so we should add a comment here stating why this is necessary.

[Rich-Harris]

this feels suuuuuper hacky, surely we can find another approach?

[trueadm]

@dummdidumm Thanks for the feedback. Fixed!

[Rich-Harris]

Opened an alternative PR that puts the encoding/decoding logic in a single hook: #13149

[dummdidumm]

Closing in favor of #13149