nuxt-buefy
nuxt-buefy copied to clipboard
[Vue warn]: Invalid prop: type check failed for prop "maxDate". Expected Date, got Date
Hello,
I am using Nuxt-Buefy (latest version) with the latest version of Nuxt (2.4.5). When I use the datepicker component and put a v-model, min-date or max-date, I have a persistent warning when the page is loaded server-side:
[Vue warn]: Invalid prop: type check failed for prop "maxDate". Expected Date, got Date
Reproducer
yarn create nuxt-app testnuxt (choose Universal)
yarn add nuxt-buefy
Add 'nuxt-buefy' module in the nuxt.config.js
Add <b-datepicker :max-date="new Date()" /> in the index.vue
When the page is loaded server-side, these warnings appear in the server console: "[Vue warn]: Invalid prop: type check failed for prop "maxDate". Expected Date, got Date " When the page is loaded client-side, there is no problem.
Nuxt version
I tested it with Nuxt 2.3.4, I had no warning and no issue. The problem exists since Nuxt version 2.4.
When I switched to version 2.4, I also had this issue which I think is the same: https://github.com/davestewart/vuex-pathify/pull/46 (in both cases it's the "instanceof" method that isn't working anymore since Nuxt 2.4)
I have a similar issue:
[Vue warn]: Invalid prop: type check failed for prop "selectedDate". Expected Date, got Date
With the code in the from an example
<template>
<b-field label="Select a date">
<b-datepicker
v-model="date"
:first-day-of-week="1"
placeholder="Click to select..."
>
</b-datepicker>
</b-field>
</template>
<script>
export default {
data() {
return {
date: new Date()
}
}
}
</script>
@SebastienTainon did you find a solution?
@ilbonte Unfortunately no, it must be in the internals of something used by Nuxt 2.4 but very hard to say what because there were a lot of code/lib updates between the two versions. If you find something, I'm interested!
i'll try to reproduce this, but the latest version of nuxt is 2.6 :)
@DonNicoJs thanks for the support :) I'm using nuxt 2.6.2 Here is a demo: https://codesandbox.io/s/yql12vywjz
@ilbonte thank you for the repro :) I forked it and did a quick test with a local custom component that exposes the same prop and.. it works. https://codesandbox.io/s/vjvnm14w6l
it's probably something related to how selectedDate is handled inside the datepicker. I need to investigate this further.
Luckily is just a warning right?
Yup, looks everything is working fine
We've also seen a similar issue with a Nuxt.js project: wrapping the b-datepicker / b-timepicker component references in <no-ssr> </no-ssr>
tags resolved the issue. (As noted, the pickers were working fine on the client, just throwing errors in the server log.)
Just an FYI for anyone looking for a workaround and a cleaner log file. (thanks to @jtommy for the hint that the issue was reported here)
@davegriffin just remember that that way you are not rendering the datepicker on the first html spit out by the server
@ilbonte @davegriffin @SebastienTainon So I investigated this issue with the help of manniL from the nuxt team.
The warning is present only in DEV and never in production, and is because of this feature: https://github.com/nuxt/nuxt.js/pull/4508
TLDR: in dev mode some components are built in parallel so the date instance is different and so instanceof
fails.
Thanks for spending time on investigating this @DonNicoJs, that's very interesting to know where these "instanceof" problems come from. And it's also interesting and reassuring to know that happens only in dev environment. If there is nothing we can do to remove them in dev (apart from not rendering the datepicker in SSR), I think that issue can be closed then.
@SebastienTainon The only thing that we could do is to remove type: Date everywhere and change it with a custom validator that validates that the object is a date without the use of instanceof
which I think is way out of the scope to remove a warning ( it would make the code less clear and more complex ) I am thinking to submit a PR to buefy to refactor the datepicker (which could potentially fix this issue ) but is far in my prio list :)
It's alright for me, as you say it's just a warning and we know why it's happening!
Seems like no one in Nuxt cares: https://github.com/nuxt/nuxt.js/issues/5565
The problem can be simplified to: new Date() instanceof Date
being false
in dev version. Ridiculous.
@IlyaSemenov Being just a warning that has no impact on functionalities I believe they have it down in their pipeline. Which make sense to me, I would rather they spend energy on bugs / bigger features
I came up with this temp fix:
<b-datepicker :min-date="minDate"></b-datepicker>
data() {
return {
minDate: undefined,
}
},
mounted(){
this.minDate = new Date()
}
Is this fine, or is it going to backfire somehow?
@vakrolme it can :) including possible differences between SSRendered and hydrated page, just for a warning I would not go in that route, but this is just my suggestion
My advice is to use .toISOString() so this isn't a problem anymore
Hi all, any suggestions on how to resolve this issue? It seems to work fine but continues to throw a big warning in the console.
A temporary fix is to clone the date object before transmitting to the child component with buggyDate = new Date(buggyDate.getTime())
@SebastienTainon @existe-deja @timwis @vakrolme Is this still an issue with the latest v2 of nuxt v2.x
?