Mention the transport hook in error messages and docs

[eltigerchino]

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

kit/packages/kit/src/runtime/server/utils.js

Lines 136 to 141 in 5594597

	return `Data returned from \`load\` while rendering ${event.route.id} is not serializable: ${error.message} (${error.path})`;
	}
	if (error.path === '') {
	return `Data returned from \`load\` while rendering ${event.route.id} is not a plain object`;
	}

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

[tabysi]

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.

[elliott-with-the-longest-name-on-github]

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