I am having irritative behaviour with my gatsby build. I can successfully run the development build using npm start but when I use to run it in production mode using gatsby build I am getting below error
error Building static HTML failed for path "/application/"
See our docs page on debugging HTML builds for help https://gatsby.app/debug-html
6097 |
6098 | function getLocaleObject(localeName) {
> 6099 | return window.__localeData__ ? window.__localeData__[localeName] : null;
| ^
6100 | }
6101 |
6102 | function getFormattedWeekdayInLocale(date, formatFunc, locale) {
WebpackError: ReferenceError: window is not defined
- index.js:6099 getLocaleObject
[lib]/[react-datepicker]/es/index.js:6099:1
- index.js:5973 formatDate
[lib]/[react-datepicker]/es/index.js:5973:1
- index.js:5990 safeDateFormat
[lib]/[react-datepicker]/es/index.js:5990:1
- index.js:8822 DatePicker._this.renderDateInput
[lib]/[react-datepicker]/es/index.js:8822:1
- index.js:8900 DatePicker.render
[lib]/[react-datepicker]/es/index.js:8900:1
- bootstrap:19 c
lib/webpack/bootstrap:19:1
- bootstrap:25 a.render
lib/webpack/bootstrap:25:1
- bootstrap:24 a.read
lib/webpack/bootstrap:24:1
- bootstrap:36 renderToString
lib/webpack/bootstrap:36:1
- static-entry.js:194 Module../.cache/static-entry.js.__webpack_exports__.defa ult
lib/.cache/static-entry.js:194:18
- bootstrap:24 Promise
lib/webpack/bootstrap:24:1
- gatsby-browser-entry.js:2 Promise._resolveFromExecutor
lib/.cache/gatsby-browser-entry.js:2:1
- bootstrap:68 new Promise
lib/webpack/bootstrap:68:1
Can someone please help why I am getting this error.
Thank you!!!
Have such error too.
I'm facing the same problem. In fact this library is not compatible with SSR (Server Side Rendering).
After a short investigation, the localization data are stored using window, which is not defined at compile-time in Gatsby. It's because this library share the locale you configure somewhere to the whole app.
@julien1619 @abobykin Could you find some work around?
@ashishlal91 Hi! As for me - don't know actually how it's all around Gatsby, have only React/Redux/Node.js in the stack I was starting working with couple of days ago.
I've made this thing working for my needs with a help of 'handleSelect' attribute. I've catched it in my React component function and then save it to the state object value which I bind to the other input below this input with datepicker which I've made transparent with CSS).
@ashishlal91 Please note that selected={this.state.date} was not working for me, right for the reason you described I suppose, I've just found this with debugger and remove this line at all from the the html component. It works only without this ) Hope it would be helpful for you!
@abobykin oh so you removed the selected option and get it worked! Great but I think this should be.fixed from the module itself. Why someone from the team is not replying
I've succeeded to make it work but the translations won't work in SSR.
To do it here is what I've done:
const isSSR = typeof window === 'undefined';
if (!isSSR) {
registerLocale('fr', fr);
setDefaultLocale('fr');
}
// In the render function
<DatePicker
selected={filter.dateStart}
onChange={this.handleDateStartChange}
locale={isSSR ? 'en' : 'fr'}
/>
Well I have found a solution.
Go to node_modules/react-datepicker/es/index.js and define the window variable
var window = require('window')
@ashishlal91 Sounds cool! I'll try it soon) But of course this folder is rewritable. Let's give it a try and then maybe offer a fix to creators of this module.
@ashishlal91 not working!
There is a PR waiting to be merged that will fix this bug : #1634
@ron766 What's not working?
I forked #1634 (needed to build and push the built files) to test it on my Gatsby build and it works. For now I'm using "react-datepicker": "github:julien1619/react-datepicker#window-fix" in my package.json file until the fix is made available.
Something like this for Browserify and Webpack:
<Datepicker selected={process.browser && this.props.date} />
For me in gatsby it's working something like that:
<DatePicker
locale="en"
selected={this.props.field.value}
dateFormat="yyyy/MM/dd"
withPortal
onChange={this.handleChange}
/>
Simply adding locale="en" to my <DatePicker> elements solved it for me.
How about that:
import DatePicker from 'react-datepicker';
import node from 'detect-node';
{!node && <DatePicker />}
... this should solve all problems
No I think it would be a dirty fix, the root cause should be fixed. I think the problem here, is that it's behaving in a different way than date-fns.
The date-fns library does not have any global configuration, it lets the user handle a configuration object. react-datepicker keeps a global configuration object whereas it should provide a similar way to configure it than date-fns. By doing it this way, it would remove the need for any global window usage.
Could there be a way to do it this way?
No I think it would be a dirty fix, the root cause should be fixed. I think the problem here, is that it's behaving in a different way than
date-fns.The
date-fnslibrary does not have any global configuration, it lets the user handle a configuration object.react-datepickerkeeps a global configuration object whereas it should provide a similar way to configure it than date-fns. By doing it this way, it would remove the need for any globalwindowusage.Could there be a way to do it this way?
I agree - it is dirty, but I need solution today/now, and issue was created 7 Feb and is still not solved.
Beside, not rendering element on the server usually will not cause problems in crawling the page (hard to believe that value of input representing this component will be important). The only issue (side effect) is that it will cause inconsistency of prerendered html to browser side rendered html using React.hydrate()
To me solution proposed here link looks even worse.
.. with all respect :)
You're completely right ;) I wrongly thought you were proposing a definitive fix, sorry if I was a little bit agressive, it was not intended.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
No I think it would be a dirty fix, the root cause should be fixed. I think the problem here, is that it's behaving in a different way than
date-fns.The
date-fnslibrary does not have any global configuration, it lets the user handle a configuration object.react-datepickerkeeps a global configuration object whereas it should provide a similar way to configure it than date-fns. By doing it this way, it would remove the need for any globalwindowusage.Could there be a way to do it this way?