isSerializable does not include Date type

[XavierGeerinck]

https://github.com/zeit/next.js/blob/master/packages/next/lib/is-serializable-props.ts#L41

Is it possible that Date as type is missing from this method? I am getting an error when trying to export my site as a static one and when the object contains date values.

Temporary workaround is to cast the date type as a string

[timneutkens]

Date is serialized to a string and then on the client-side would cause a hydration error as Date is expected to be a date object in most cases.

[Timer]

@thebillkidy to explain a bit further, during server-side renders (in production) we skip the serialization step for performance reasons.

This means your server-render would have access to the Date (and date.getHours() would work).

Then, on the client, it'd try calling .getHours() on a string which would give you a TypeError or hydration mismatch.

To remedy this, we do a serialization check only during development!

[XavierGeerinck]

Aha, ok now I understand it! :) thanks a lot, this can be closed then.

[AshConnolly]

Hi @Timer & @timneutkens! 👋
Thanks for explaining why this is happening, I now understand.
However, I'm not sure how to solve this. Do you have a recommended solution?

I'm currently fetching data from mongoDB and both the date fields and document _ids cause the cannot be serialized as JSON error.
The only way I seem to be able to pass this data is if i stringify it in getStaticProps, then parse it in the component. But I'm suspect this is an anti pattern and there's a better way! 😃

Any help is hugely appreciated! Thanks 👍

[Timer]

You should run a .map() across the array returned by mongo.

[AshConnolly]

Hi @Timer! Thanks for the reply! 😃

I tried that and the same error occurs. I have a large object with several nested objects and arrays, partially containing dates and ids.

• Is there any way to pass these dates and ids without causing the serialising issues?
• Is stringifying in getStaticProps, and parsing in the component a bad idea?

Another question (for a different situation to my current one) would be is there any reliable way to 'deep' remove the data causing these issues?

Thanks mate! Any help is greatly appreciated! 😃

[sandcastle]

See #13696 for a proposed solution to this issue

[ivawzh]

Hi @Timer

If I have read it correctly, NextJs is always using JSON.stringify to serialize the data payload:

• server
• incremental cache
• api

And JSON.stringify(new Date()) // "2020-08-06T10:22:57.118Z" does handle date-to-string correctly.

The purpose of this existing Date validation seems suppose to act as a server-client API typing glue. But the current way is more like an unnecessary API restriction. And we have date fields on every record, this is troublesome to manage and I believe it's bad for performance.

As we are using TypeScript, we'd prefer to leave the typing concerns to it if possible. Such as adding an enhanced version of InferGetServerSidePropsType mapped type to transform all Date to string like this.

Do you see any problem with this approach?

I understand that not everyone is using TypeScript with NextJs. Can you allow users to opt-out the development-time Date restriction, so that we can implement the mapped type ourselves?

[marceloverdijk]

Hi @Timer, @timneutkens,

Although the question is marked as answered, for me it is not clear yet what would be the best pattern to use.
I'm having a TypeScript with Prisma setup where I query nested objects from the database containing date fields.

What I'm thinking of now is to create DTO objects that mimic the database models but where the date fields are strings. Then write some mappers to transform the database models to the "JSON" DTO's and pass these from getStaticProps.

Is that a pattern others are using as well?

Just JSON stringifying won't help as I will lose type safety in the React frontend components.

It is a pity that all online examples, blogs don't use dates - on purpose? - so the examples look really simple and don't give any hints what would be a pattern to solve this.

[Manubi]

@timneutkens any chance you're adding superjson? :) I think more and more people will have the problem with Dates in postgres...

[nonoumasy]

just to clarify, do you just need to install the following to fix the issue:
npm install babel-plugin-superjson-next
npm install superjson

and add this file to the root
.babelrc
{
"presets": [
"next/babel"
],
"plugins": [
"superjson-next" // 👈
]
}

or is there more you have to do?
Do you need to serialize and deserialize it?

[richardthombs]

Looking back at the commit where I added superjson to my project, I think you are right. All you need to do is npm install those packages and update .babelrc.

[bennettdams]

superjson works great, but keep in mind that every date in the object you're serializing will occur two times in the JSON file that Next.js sends to the browser. That's because the "type" information of the object values are saved in the JSON as well. If you want to see that directly, search for "_superjson" in your JSON file.
In my case, the impact of that was massive. It doubled the size of the JSON, as I'm working with a lot of dates for chart data. For this use case, I have to disable superjson.

[FranciscoKloganB]

The repository instructs us to install a babel plugin as a production dependency?

Is this expected?

[andrasf]

It is almost 2022 and I have to workaround serializing a date. Pls!

[gergelypap]

Since Babel is replaced by SWC in NextJS 12, the superjson/babel-plugin-superjson-next method is not working with the new compiler. See flightcontrolhq/superjson#157

[SEBIIWA]

since no one mentioned it and i've seen people saying that superjson might not work.
I found this simple solution on this link where you wrap the data returned from the getServerSideProps() in a JSON.stringify() then inside a JSON.parse() and this would avoid the problem mentioned above by team maintainer

I am using prisma so my function looks like this

export async function getServerSideProps() {
  const user: User[] = await prisma.user.findMany()
  return {
    props: {
      initial: JSON.parse(JSON.stringify(user)),
    },
  }
}

and this is DATETIME type in my schema is what was causing the problem in my case.

model User {
  id          String      @id @default(auto()) @map("_id") @db.ObjectId
  email       String      @unique
  password    String      
  role        Role        @default(SIMPLE)
  createdAt   DateTime    @default(now())       @map(name: "_createdAt")
  updateAt    DateTime    @updatedAt            @map(name: "_updatedAt")
  info        UserInfo?
}

[mcgrealife]

@nyuuke this works! Although a major downside is that the props lose their Prisma types inference.

Manual type casting solves it, I.e.
return { props: { initial: JSON.parse(JSON.stringify(user)) as User[] }, }

But it is not flexible to type changes. Does anyone know how to solve it without type casting?

[anthonyalayo]

For others who have come here recently, the superjson route isn't worth exploring. SWC has replaced babel, so superjson out of the box forces you to bring babel back. On top of that, the package next-superjson tries to be less damaging but instead removes all breakpoint debug support. It would be nice for next to provide a solution to this.

[jokull]

This is the solution: https://github.com/blitz-js/next-superjson-plugin