Replies: 2 comments 1 reply
-
Regarding Date and JSON: we had a couple of issues opened from people being confused that their Date objects got strings, which was one of the drivers for this sanity check. So while I understand your frustration, there are also many people who will now know of this. The question is whether or not we should make Date a special case and only warn, or make this a warning rather than an error in general. |
Beta Was this translation helpful? Give feedback.
-
This would be solved by #6008. This isn't just a type safety concern. It's about the fact that if you return a export let date;
$: year = date.getFullYear(); ...but it would fail in the browser. That's far more chaotic than a requirement to return data that can safely be serialized, which (as you demonstrated) is easily achieved. If we did as you suggest and allowed any return value that |
Beta Was this translation helpful? Give feedback.
-
tldr; Everything that is JSON-serializable should be serializable. In the real world, folks are going to have to short-circuit SvelteKit's serializable check anyway, as I do below. Also, type safety (as opposed to generated types) should be a userland concern.
The Dilemma
As of a couple of days ago SvelteKit decides for the developer what is JSON-serializable and what isn't. As far as I can tell, this constraint stems from the desire to strongly type
data
between server and client code -- i.e., the merged typings that Kit puts in./$types
.One of the things that SvelteKit "says" is not JSON-serializable is
Date
. Now, my application database is littered withDate
s. You can't swing a stick without hitting one on the head. So I was faced with a dilemma:The Solution
In the end I went with the latter.
Usage example:
A word about "type safety" and
./$types.d.ts
I get that generated types are necessary since the introduction of the
+layout.server.js
tree. But those types are not from nowhere. They're ultimately coming from userland, e.g. myBaseLayoutData
type in the usage example above."Type safety" (as opposed to type generation) is therefore firmly on the userland side. If I say something is a
Date
then just take my word for it, serialize it, and let me deal with the consequences, horrific or not.More or less same goes if I say something is a
BigInt
(i.e. not JSON-serializable.) If by accident I return an unserializedBigInt
,JSON.stringify
will throw. SvelteKit doesn't have to be involved at all. (TheBigInt
case for me is way less common thanDate
, but it does exist.)Alternatives
I may be missing something, but
itsMyPartyAndICanCryIfIWantToCryIfIWantToCryIfIWantTo
aside, there is no reasonable alternative for my current application. The ORM (Prisma) I'm using has no option as far as I can tell to returnDate
as string, and the ORM is baked in even deeper than SvelteKit (i.e. I'd reluctantly ditch Kit before ditching the ORM.)It seems to me the only reasonable solution is for SvelteKit to allow all JSON-serializable things. The "generated types" documentation can have copious caveats, along with "here's how to revivify a Date from a string in the browser" or "make sure you stringify BigInts before returning them, here's how" examples for common cases.
Thanks for reading! Let me know what you think, or if I am indeed missing some way around this.
Beta Was this translation helpful? Give feedback.
All reactions