feat: allow serialization/deserialization of custom data types (alternative API)

[Rich-Harris]

Alternative to #13125, Closes #9401. Instead of separating the logic between hooks.server.js and hooks.client.js, this puts both things in hooks.js. Initially I thought the separate made more sense, but I'm not so sure. In essentially all cases, you'll need a reference to the custom type — for an instanceof check during serialization, and for instantiation during deserialization — so there doesn't really seem to be a benefit to keeping them in separate files.

Putting them in one place is easier to understand, and means you can't end up with mismatches. It does mean that the serialization logic ends up in the client, but we're talking about a few bytes for a value instanceof Foo && [value.blah] function.

I'm not too sure about the naming of things. Right now it looks like this:

// hooks.js
import { MyCustomThing } from '$lib/stuff';

export const transport = {
  MyCustomThing: {
    encode: (value) => value instanceof MyCustomThing && [value.blah],
    decode: ([blah]) => new MyCustomThing(blah)
  }
};

TODO:

• add a type for the export (ultimately, this should be added automatically just like other hooks)
• documentation

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com./sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 177d2b9

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-13149-svelte.vercel.app/

this is an automated message

[benmccann]

I would prefer a version where you can tree-shake the server code:

export const transportEncode = {
  MyCustomThing: (value) => value instanceof MyCustomThing && [value.blah]
};

export const transportDecode = {
  MyCustomThing: ([blah]) => new MyCustomThing(blah)
};

[Rich-Harris]

We're talking about a few bytes, unless you have a realistic example to the contrary? I don't think the trade-off is a good one

[dummdidumm]

How much use will people really make of this specific type, since it's not helping much with type safety? Should we just omit it?

[paoloricciuti]

I still think we should at least offer the defineTransport function for type safety. We can call it something else if we don't like it but it would be nice

[Rich-Harris]

It's helping plenty — it might not be able to provide inference for the decode parameter, but it enforces the correct shape of transport (i.e. you can't omit either encode or decode for a given transporter, and you can't misspell them). And exposing Transporter means you can add the missing type safety yourself:

export const transport: Transport = {
  Foo: {
    encode: (value) => ...,
    decode: (data) => ...
  } satisfies Transporter<Foo, [blah]>
};

We could always add defineTransport later if we feel like we need to, but I don't think we should break with existing conventions just yet.

[paoloricciuti]

@dummdidumm can we add this to 0 effort typesafe?

[dummdidumm]

Yes and no - we can add satisfies Transport for the top level, but we can't do much for the individual entries

[AlbertMarashi]

Amazing stuff!