Warning: Expected Instance Props to Match Memoized Props

[BigPrimeNumbers]

When updating react and react-dom from 16.6.0 to 16.6.1 or 16.6.2, I get new warnings that did not occur prior:

Warning: Expected instance props to match memoized props before componentDidMount. This is likely due to a bug in React. Please file an issue.
Warning: Expected instance props to match memoized props before componentDidUpdate. This is likely due to a bug in React. Please file an issue.
Warning: Expected instance props to match memoized props before processing the update queue. This is likely due to a bug in React. Please file an issue.

all from react-dom.development.js?ec6d:506

I am unable to give you examples from the code as I am not sure where this is occurring and the stacktrace comes from deep in react-dom and is unfollowable from my code, though it happens on every page visited within the app. Reverting back to 16.6.0 versions removes the warning completely.

There exists at least one other with the same problem: https://stackoverflow.com/questions/53272887/expected-instance-props-to-match-memoized-props-in-react-16

[gaearon]

Sorry, we’ll need a reproducing example to fix this. Even if you can’t share your app’s code, here is a good guide to creating one: http://sscce.org/

[dxcqcv]

I have the same problem, and I can reproducing example using my yoman generator

so the steps is

1. npm install -g yo (if you do not install yoman)
2. npm install -g generator-webpack-humble
3. yo webpack-humble
4. select use React with react-css-modules and react-redux and redux-thunk
5. run npm run dev after all dependents installed
6. then you'll see Warning: Expected Instance Props to Match Memoized in browser console

And I already found the key of problem is componentDidMount hook, if I removed it the warning is disappeared

[hardchopshoppirate]

Hi there,
For me, it's reproduced with react: 16.6.* and rxjs: 6.3.3. I found that without initializing of rxjs it works fine only on react: 16.6.1 and lower. Maybe it will be helpful for you to reproduce the issue.
Thanks!

UPD: reproduced only on webpack-dev-server running :)

[edgeadjei]

I'm having the same issue after updating both react and react-dom to ^16.6.3. And with a bundle size of 3.6 mb excluding node modules reproducing the issue will be rough.

[adamthompson922]

I have been experiencing the same issue and have isolated it to using the latest react-css-modules with create-react-class. When migrating to use ES6 class components, the error disappears.

Here is a minimal example.

Thanks to @gaearon for the suggestions to isolate the issue on /r/reactjs.

[gaearon]

Looking at the reproducing code in https://codesandbox.io/s/xppzppmpv4, this is because the library you're using (react-css-modules) contains code like this:

    WrappedComponent.prototype.render = function render() {
      // ...

        this.props = props;

It is not supported to override this.props yourself. It's provided by React. The fact that this code even works is entirely accidental. I would suggest to file an issue with react-css-modules or migrate away from that project. It is common knowledge that React render methods are intended to not mutate data, and mutating this.props itself is very aggressive and will lead to more issues in the future.

[gaearon]

As an alternative, of course, they could restore it back in a try/finally block.

// ...
const originalProps = this.props;
try {
  this.props = props;
  // ...
} finally {
  this.props = originalProps;
}

Again, this is not recommended, but it would work around the issue.

[gajus]

@gaearon Is this what you mean?

/* eslint-disable react/prop-types */

import _ from 'lodash';
import React from 'react';
import hoistNonReactStatics from 'hoist-non-react-statics';
import linkClass from './linkClass';
import renderNothing from './renderNothing';

/**
 * @param {ReactClass} Component
 * @param {Object} defaultStyles
 * @param {Object} options
 * @returns {ReactClass}
 */
export default (Component: Object, defaultStyles: Object, options: Object) => {
  const WrappedComponent = class extends Component {
    render () {
      let styles;

      const hasDefaultstyles = _.isObject(defaultStyles);

      if (this.props.styles || hasDefaultstyles) {
        const props = Object.assign({}, this.props);

        if (props.styles) {
          styles = props.styles;
        } else if (hasDefaultstyles) {
          styles = defaultStyles;
          delete props.styles;
        }

        Object.defineProperty(props, 'styles', {
          configurable: true,
          enumerable: false,
          value: styles,
          writable: false
        });

-        this.props = props;
+        const originalProps = this.props;
+
+        try {
+          this.props = props;
+        } finally {
+          this.props = originalProps;
+        }
      } else {
        styles = {};
      }

      const renderResult = super.render();

      if (renderResult) {
        return linkClass(renderResult, styles, options);
      }

      return renderNothing(React.version);
    }
  };

  return hoistNonReactStatics(WrappedComponent, Component);
};

[gaearon]

Yes. Note that props would still be "wrong" in componentDidMount and other lifecycle methods. As well as prevProps in componentDidUpdate. Assigning them like this was never intentionally supported so I'm not actually sure what the behavior used to be with your existing code, and which APIs worked correctly.

[gaearon]

Oh wait. Sorry. No that wouldn't be useful.

I meant something like this:

+      try {
+        this.props = props;
         const renderResult = super.render();
+      } finally {
+        this.props = originalProps;
+      }

I assumed the reason you want to assign fake this.props is so that the base render "sees" them.

[gaearon]

To clarify. I mean that it's not supported to ever overwrite this.props in a React component. The fact that it worked in that module is an accident. There are absolutely no guarantees attached to that.

To limit the scope of the issue it introduces, my proposal is to "revert" them back right after calling super.render. I guess it still breaks event handlers etc, so maybe this isn't helpful.