Errors when upgrading to latest react-dates

[jnrepo]

upgrading from 12.1.0 to 13.0.3

After installing the new module running into these errors, I think its something to do w/ storybook?

Uncaught TypeError: Cannot read property 'theme' of undefined

and

Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in. Check the render method of `SearchFilters`.

and

Uncaught Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in. Check the render method of `SearchFilters`.

Wondering if anyone else ran into these, and if there is a fix for them. Thanks in advanced!

[ljharb]

Please read the docs - did you import 'react-dates/initialize' at the top of your app?

[majapw]

As @ljharb, the README includes instructions for setting up v13 properly! :) We introduced a breaking change that requires a tiny bit more set-up.

[icd2k3]

I followed the instructions and am still getting the error...

react: 16.0.0
webpack: 3.5.6
react-dates: 13.0.4

index.jsx

import 'react-dates/initialize';
import 'react-dates/lib/css/_datepicker.css';
import React from 'react';
// ...

MyDatePickerForm.jsx

import { SingleDatePicker as DatePicker } from 'react-dates';
// ...
<DatePicker
  date={dueDate}
  focused={this.state.focused}
  numberOfMonths={1}
  onDateChange={this.handleDateChange}
  onFocusChange={({ focused }) => this.setState({ focused })}
  placeholder="Due Date (optional)"
/>

Uncaught TypeError: Cannot read property 'theme' of undefined
    at Object.create (webpack:///./node_modules/react-with-styles/lib/ThemedStyleSheet.js?:33)
    at withStyles (webpack:///./node_modules/react-with-styles/lib/withStyles.js?:78)
    at Object.65 (webpack:///./node_modules/react-dates/lib/components/DateInput.js?:467)
    at __webpack_require__ (webpack:///./node_modules/react-dates/lib/components/DateInput.js?:21)
    at eval (webpack:///./node_modules/react-dates/lib/components/DateInput.js?:67)
    at eval (webpack:///./node_modules/react-dates/lib/components/DateInput.js?:70)
    at Object../node_modules/react-dates/lib/components/DateInput.js (koan-common-c4c2dc63e3cd20358949.js:6854)
    at __webpack_require__ (koan-common-c4c2dc63e3cd20358949.js:713)
    at fn (koan-common-c4c2dc63e3cd20358949.js:118)
    at Object.34 (webpack:///./node_modules/react-dates/lib/components/DateRangePickerInput.js?:333)
webpack:///./src/index.jsx?:12 Uncaught Error: Cannot find module "react-dates/lib/css/_datepicker.css"
    at eval (webpack:///./src/index.jsx?:12:7)
    at Object../src/index.jsx (http://dojo.local.koan.co:3000/koan-app-c4c2dc63e3cd20358949.js:6300:1)
    at __webpack_require__ (http://dojo.local.koan.co:3000/koan-common-c4c2dc63e3cd20358949.js:713:30)
    at fn (http://dojo.local.koan.co:3000/koan-common-c4c2dc63e3cd20358949.js:118:20)
    at eval (webpack:///multi_(webpack)-dev-server/client?:4:18)
    at Object.0 (http://dojo.local.koan.co:3000/koan-app-c4c2dc63e3cd20358949.js:7687:1)
    at __webpack_require__ (http://dojo.local.koan.co:3000/koan-common-c4c2dc63e3cd20358949.js:713:30)
    at webpackJsonpCallback (http://dojo.local.koan.co:3000/koan-common-c4c2dc63e3cd20358949.js:26:23)
    at http://dojo.local.koan.co:3000/koan-app-c4c2dc63e3cd20358949.js:1:1

[majapw]

@icd2k3 MyDatePickerForm.jsx is definitely being loaded after the code in your index.jsx file?

Does the same thing happen if you do

import DatePicker from 'react-dates/lib/components/SingleDatePicker';

?

[icd2k3]

@majapw yea it is - just to be sure, I moved the imports directly into the top of MyDatePickerForm.jsx and still have the issue (same for import DatePicker from 'react-dates/lib/components/SingleDatePicker').

What's strange too, is after upgrading I don't see a css folder in ./node_modules/react-dates/lib... Shouldn't there be? I tried yarn remove react-dates -> yarn add react-dates to do a full reinstall and still no dice.

[majapw]

Hmm, this is really weird. I'll have to investigate... maybe it's something to do with React 16?

The css folder is gone from the npm package because it no contains anything useful (it just contains some css for the storybook). The CSS file in lib is built from the components themselves.

[nooysters]

This one is no longer found and it was providing the main styles for the component I believe.
import '!style-loader!css-loader!react-dates/lib/css/_datepicker.css'

import 'react-dates/initialize' fixes the Uncaught TypeError: Cannot read property 'theme' of undefined but not the

ERROR in ./node_modules/playa-styleguide/src/components/DatePicker/DatePicker.js
Module not found: Error: Can't resolve 'react-dates/lib/css/_datepicker.css' in '/Users/jeremyazzari/Workspace/h1/hyfn8_front_end_app/node_modules/playa-styleguide/src/components/DatePicker'

[geryit]

[dorianWB]

804fb1d was a breaking change I believe and I guess is related to the breaking change that was supposed to go out in 13.0.0 because we had 13.0.3 working with the old style imports until today. We did have to add an alias and import the initialize js to fix the issue @nooysters mentioned above 2 days ago though.

[matix]

Same issue here, just trying to make the component work on a simple, isolated page:

  const React = require('react');
  require('react-dates/initialize');
  require('react-dates/lib/css/_datepicker.css');
  const {DateRangePicker} = require('react-dates');

  module.exports  = function Test () {
      return (
        <DateRangePicker onDatesChange={()=>{}}
          onFocusChange={()=>{}}/>
      );
 }

{
  "devDependencies": {
     "babel-core": "^6.22.1",
     "babel-loader": "^6.2.10",
     "babel-preset-es2015": "^6.22.0",
     "babel-preset-react": "^6.22.0",
     "webpack": "^2.2.1"
  },
  "dependencies": {
    "moment": "^2.17.1",
    "react": "^15.4.2",
    "react-addons-shallow-compare": "^15.6.2",
    "react-dom": "^15.4.2",
    "react-dates": "^13.0.4",
  }
}

Compilation error on webpack:

ERROR in Test.js
Module not found: Error: Can't resolve 'react-dates/lib/css/_datepicker.css' in '[REDACTED]'
 @ [REDACTED]/Test.js 5:2-48
 @ [REDACTED]/init.js
 @ multi (webpack)-dev-server/client?https://localhost:8000 webpack/hot/dev-server [REDACTED]/init

Effectively react-dates/lib/css/_datepicker.css is not being generated.
Tried installing with both npm v3.10.10 and yarn v0.23.2, same result.

Removing the css dependency fixes the compilation error, but the component is rendered without styles as expected.

Are we supposed to manually run node_modules/react-dates/scripts/buildCSS.js to generate the css?
or
is the script meant to run as a post-install step for the module and it's failing for some reason ?

[erin-doyle]

Running the build script in the latest checkout of react-dates I can see that the css dir does get created successfully. I'm wondering if maybe there was just a blip of some sort during the publishing of this latest version and if another push would fix it. I am guessing the issue relies totally in a build artifact missing not a bug in the code or implementation problem.

EDIT: or maybe this is the root cause: 804fb1d
ignoring css from npm tracking

[majapw]

But that shouldn't affect... lib/css, should it?

Also the css missing issue is different from the error presenting here on the theme.

[dorianWB]

@majapw The title of the open issue is "errors when upgrading to latest react-dates", so I think thats why we found it appropriate to comment on the missing css in the latest react-dates here, not to mention they are related to the same set of changes. Would it help to open a separate issue specifically about the css?

[majapw]

Okay I was... unfamiliar with the particular of npmignroe patterns. The missing css issue should be resolved in 13.0.5.

As for

804fb1d was a breaking change I believe and I guess is related to the breaking change that was supposed to go out in 13.0.0 because we had 13.0.3 working with the old style imports until today.

I don't believe we ever recommended importing the prebuilt CSS files, and if so, we def did not support it as of v13 so I think it's a bit of a ??? as to whether to consider it breaking or not. :/

In either case, I am still unsure as to why the missing theme error is still there. Will continue digging on that!

[ljharb]

Indeed, importing any unbuilt files isn't part of our API, so removing it isn't a breaking change.

[dorianWB]

The readme said this, before f3e731e:

react-dates comes with a set of SCSS variables that can be overridden to add your own project-specific theming. Override any variables found in css/variables.scss with your own and then import ~react-dates/css/styles.scss (and ~react-dates/css/variables.scss if you're only overriding a few).

so that's what we did.

@ljharb Call it what you want, but the component stopped working properly after this release because we followed those instructions.

@majapw I admit our use case is far from normal, but I don't know far it is from recommended given that following these instructions were enough to keep it working.

[majapw]

Fair point @dorianWB. I will call it a patch for behavior that should have been removed in v13, especially since variables.scss didn't work anymore so there was no option to override. 😬

[icd2k3]

Thanks @majapw - 13.0.5 fixed the Error: Cannot find module "react-dates/lib/css/_datepicker.css" error. The theme error is still there, however.

[erin-doyle]

Yep 13.0.5 is good for me too, back to the theme error! In debugging our app I can tell so far it that create() in ThemedStyleSheet is getting called before registerTheme() gets called.

Because we have webpack splitting our bundle into a main (our code) bundle and a vendor (3rd party libs) bundle it seems as if there is some kind of initializing of the modules in the vendor bundle that takes place before our index.js is run in the main bundle. So I have this for a stacktrace:

create | @ | ThemedStyleSheet.js?0e9a:32
-- | -- | --
  | withStyles | @ | withStyles.js?5fe2:77
  | 65 | @ | DateInput.js?5beb:432
  | __webpack_require__ | @ | DateInput.js?5beb:13
  | (anonymous) | @ | DateInput.js?5beb:38
  | (anonymous) | @ | DateInput.js?5beb:40
  | (anonymous) | @ | vendor.9b8fb67….js:2667
  | __webpack_require__ | @ | manifest.9b8fb67….js:711

And this happens before my breakpoint in ThemedStyleSheet registerTheme() is hit which gets run at the beginning of my index.js

import 'react-dates/initialize';

per the README instructions.

Workaround:_ By removing react-dates from our vendor bundle I am now no longer receiving the error.

[icd2k3]

+1 to @erin-doyle - I too had react-dates in a separate entry chunk (our code is split like entry: { app: [ ], common: [ ] }... removing react-dates from the common chunk solved the theme issue for me

[majapw]

@erin-doyle @icd2k3 is there any way you could add a snippet to the README to better describe your solution?

[icd2k3]

@majapw well it fixes the error, but it's actually not a great solution.

I would like to keep react-dates in my webpack common entry chunk because my project utilizes a lot of code splitting. Because react-dates is used in a lot of places in my app this adds a lot of file size because it is now included in every code-split chunk that uses it.

For example, 12.6.0 was only included in common.js, whereas now in order to use 13.x the same react-dates source code will be included in homepage.js, reports.js, etc.js. This adds a lot to the overall loading time as the user clicks around the app.

So, now that we know what the issue is, I'd like to look for a better solve which allows me to keep react-dates in my separate entry chunk.

EDIT: here is my entry config for webpack for clairity

  entry: {
    app: IS_LOCAL
      ? ['react-hot-loader/patch', ENTRY]
      : ENTRY,
    common: [
      'asn1.js',
      'browserify-aes',
      'draft-js-mention-plugin',
      'draft-js-emoji-plugin',
      'draft-js-plugins-editor',
      'elliptic',
      'react-addons-css-transition-group',
      'react-redux',
      'readable-stream',
      'react-dates',  // <---- this causes the theme error
      'linkify-it',
      'tlds',
      'victory',
      'victory-core',
      'victory-chart',
    ],
  },

[erin-doyle]

I agree with @icd2k3. So I've changed where I said "Solution" to instead say "Workaround".

I wonder if the ThemedStyleSheet can be modified such that the styleTheme and styleInterface weren't mutable especially such that there isn't the possibility of calling create() out of order from registering the theme and interface. I feel like that there is the problem.

[majapw]

Hmm, we're still definitely working out the kinks of using RWS in the wild (so react-dates is def the playground for this process). One thing we do internally is that we have a withStyles file that does

import aphroditeInterface from 'react-with-styles-interface-aphrodite';
import globalCache from 'global-cache';
import ReactWithStylesThemedStyleSheet from 'react-with-styles/lib/ThemedStyleSheet';
import { css, cssNoRTL, withStyles, withStylesPropTypes } from 'react-with-styles';
import AirbnbDefaultTheme from './AirbnbDefaultTheme';

const ThemedStyleSheet = globalCache.setIfMissingThenGet(
  'withStyles',
  () => {
    // Registering the default theme more than once clobbers all of the
    // previously created styles, which causes errors to happen. This can happen
    // if this file appears in more than one bundle on the same page. To avoid
    // this, we are using a global cache.
    ReactWithStylesThemedStyleSheet.registerTheme(AirbnbDefaultTheme);
    ReactWithStylesThemedStyleSheet.registerInterface(aphroditeInterface);
    return ReactWithStylesThemedStyleSheet;
  },
);

export {
  ThemedStyleSheet,
  css,
  cssNoRTL,
  withStyles,
  withStylesPropTypes,
};

and then every individual component imports from this file instead of from react-with-styles directly, ie we'd do:

// DateRangePicker.jsx
import { css, withStyles, withStylesPropTypes } from '../utils/withStyles`;
...

This ensures that the theme and interface is always set when you import a component, but unfortunately also marries the implementation to a particular interface and theme which is... less ideal.

@lencioni do you have any thoughts on this thread?

[gdborton]

@icd2k3 @erin-doyle Could you post more of your webpack config?

If I'm understanding this issue correctly, you're seeing that errors are happening when you pull react-dates into a common vendor chunk, that doesn't occur when you don't. Are you utilizing the CommonsChunkPlugin at all, or do you just build the two chunks app and common?

[erin-doyle]

Here's a scaled down example of what we're doing:

const allEntries = {
    // add the main entry for our app
    main: ['babel-polyfill', jsPath],
    // tack on a seperate entry for major dependencies
    vendor: [
        'axios',
        'classnames',
        'immutable',
        'moment',
        'moment-timezone',
        'react',
        'react-a11y-utils',
        // 'react-dates',   // <==== I had to remove this here
        'react-dom',
        'react-immutable-proptypes',
        'react-intl',
        'react-intl-redux',
        'react-redux',
        'react-router',
        'react-router-redux',
        'redux',
        'redux-form',
        'redux-immutable',
        'redux-localstorage',
        'redux-localstorage-immutable',
        'redux-offline',
        'redux-saga',
        'reselect'
    ]
};

const config = {
    resolve: { // put options affecting module resolution in here
        modules: [path.resolve(src), 'node_modules'] // absolute path for dir containing all of the app's modules
    },
    entry: allEntries,
    plugins: [
        new webpack.optimize.CommonsChunkPlugin({
            names: ['vendor', 'extra', 'manifest'],
            minChunks: 3
        })
    ]
};

[DaveCole]

I too am seeing this behavior if I just npm install --save it out of the box. Hoping for a fix soon!

[majapw]

@DaveCole is it due to your webpack config? are you importing the initialize script as per the readme?

[icd2k3]

@DaveCole you shouldn't see the theme undefined error if you're not utilizing webpack code chunk splitting and have followed the instructions in the readme.

@gdborton I could post more of my webpack config, but it's really similar to @erin-doyle's

[janpe]

What is the status on this? I'm seeing the same errors even though I am importing initialize before using any of the components.

[ljharb]

@janpe what errors? see #811 as well; if it's the same, please comment there; if different, please file a new issue.

[janpe]

The ones in the initial post on this issue. I'm not sure I understand. Both this and #811 unresolved so why is my comment not relevant here?

[icd2k3]

@janpe are you using entry code chunk splitting in webpack?

[erin-doyle]

Maybe the question is, should we either:

1. Add something to the README about code chunking being impacted by this
2. Do we need to look at this as a bug that we need to do more in react-dates to not impact the way people are chunking their code

Or 1 and then 2?

[majapw]

I think 1 and then 2 seems like the right call. I'm not super familiar with webpack and my bandwidth is def... very overwhelmed right now, but I can try and sit down with folks here to see what we can do to address this (when I get back from PTO in two weeks).

[smakosh]

This is what it shows up on the screen

Edit: I switched to this nice npm package: https://reactdatepicker.com

[dwjft]

After a new deployment today I am seeing this error in the console.

Uncaught TypeError: Cannot read property 'theme' of undefined

It appears this error has persisted for a while, and there has been no solution offered. What is odd, is that we were not experiencing this issue previously. I'm assuming one of these releases has caused the issue to re-surface:

'15.5.2': '2017-12-16T05:03:54.457Z'
'15.5.3': '2017-12-17T05:56:05.158Z'

We are using webpack and the CommonChunksPlugin to put react-dates in a vendor file.

Please advise.

[erin-doyle]

I think the advice is still the same as it is earlier on in this thread:

Workaround:_ By removing react-dates from our vendor bundle I am now no longer receiving the error.

[dwjft]

FYI, pinning react-dates to v15.5.1 solved the issue.

[ljharb]

I think this has been addressed; pinning to v15 isn't a long term solution, and the solutions with v16 have been discussed in this thread already.

If anyone is still having problems, please file a new issue :-)