kit icon indicating copy to clipboard operation
kit copied to clipboard

Mention the transport hook in error messages and docs

Open teemingc opened this issue 6 months ago • 2 comments

Describe the problem

We can now transport non-POJOs from the server to the client using the transport hook. However, this is not mentioned in the loading data section of the docs and the error message from trying to serialise the non-POJO https://github.com/sveltejs/kit/blob/55945970265adf59c24ca2fab2474417cf5c4829/packages/kit/src/runtime/server/utils.js#L136-L141

Describe the proposed solution

We should talk about the transport hook and add a link in the two situations described above. We'll need to update the "Data must be serializable" test to expect the new error message too.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

teemingc avatar Jun 11 '25 09:06 teemingc

Thanks for the proposal! I can see the benefit of using the transport hook for specific advanced use cases, but I believe we need to be very cautious here.

One of the core principles in SvelteKit is that data returned from load() must be serializable – which ensures predictability, safety, and compatibility across different rendering modes (SSR, prerender, edge, etc.). Allowing non-POJOs to be transported implicitly risks introducing several issues:

  • Unclear developer expectations – not everyone will realize non-POJOs can be transferred
  • Future compatibility problems – e.g., with prerendering, streaming, or persistent caching
  • Reduced maintainability and portability – across runtimes or when debugging complex bugs

If transport introduces an exception here, this should be very clearly documented and include warnings and examples – making it clear that this is not the recommended default approach.

Otherwise, there’s a high chance developers will unknowingly send complex objects that can't be reliably serialized, leading to subtle bugs or broken client-side behavior.

Suggestion: Encourage explicit serialization/deserialization (e.g. .toISOString() for Date objects) rather than silently allowing non-serializable objects to pass through.

tabysi avatar Jun 11 '25 10:06 tabysi

@tabysi please do not use AI to post comments on this repo

Can I tackle this one?

hamboomger avatar Jul 12 '25 18:07 hamboomger

Can I tackle this one?

Absolutely!

teemingc avatar Jul 14 '25 01:07 teemingc