Fix #6114 - Calling setState inside getChildContext should warn #6121

raineroviir · 2016-02-25T19:13:19Z

It doesn't pass one of the tests, but I'm curious if this is the right direction or not.

jimfb · 2016-02-25T19:22:55Z

src/renderers/shared/reconciler/ReactCompositeComponent.js

@@ -498,6 +498,7 @@ var ReactCompositeComponentMixin = {
    var inst = this._instance;
    var childContext = inst.getChildContext && inst.getChildContext();
    if (childContext) {
+      ReactCurrentOwner.processingChildContext = true;


Probably don't want to attach this to ReactCurrentOwner, since it has nothing to do with owners. But conceptually, yes, we want to set some sort of value when we start a getChildContext.

I think it probably makes sense to use the new devtools api here. You can emit an event when you start/end getting the child context, and keep the state in a devtool instead of tying it into the core. Devtool api details: https://github.com/facebook/react/pull/5590/files

Are there any examples of the Devtool api used in React code?
Would I be writing my own devtool function or do I use something like ReactDOMInstrumentation.debugTool.onSetValueForProperty(inst, 'processingChildContext', true)

Would I be writing my own devtool function or do I use something like ReactDOMInstrumentation.debugTool.onSetValueForProperty(inst, 'processingChildContext', true)

I think both. Here’s another example of adding a devtool for warnings: 251d6c3

onSetValueForProperty() will not be relevant here, it’s only called this way because it is called when React sets a value for DOM property.

In your case, you can add onBeginProcessingChildContext() and onEndProcessingChildContext(), and a new ReactInvalidSetStateWarningDevTool (or something like this) that would set the flag.

Also, since it’s related to React and not ReactDOM in particular, perhaps it makes sense to use ReactInstrumentation introduced in #6068 instead of ReactDOMInstrumentation.

Cool , Thanks!

So I notice I can't extend the internalInstance object to add the flag (that we are processingChildContext). What is a good object to add the flag to?

facebook-github-bot · 2016-02-27T04:08:04Z

@raineroviir updated the pull request.

jimfb · 2016-02-27T15:45:56Z

src/isomorphic/ReactDebugTool.js

@@ -48,6 +48,12 @@ var ReactDebugTool = {
      }
    }
  },
+  onBeginProcessingChildContext(instance, boolean) {


boolean is a type. A good variable name would be something like isPprocessingChildContext. But why does this variable exist at all? Isn't it always true in this function and always false in the other?

facebook-github-bot · 2016-02-27T19:39:28Z

@raineroviir updated the pull request.

facebook-github-bot · 2016-02-27T21:07:59Z

@raineroviir updated the pull request.

gaearon · 2016-02-28T12:51:10Z

src/isomorphic/devtools/ReactInvalidSetStateWarningDevTool.js

+    if (processingChildContext === false) {
+      return;
+    }
+    warning(


It might be more compact to write

warning( !processingChildContext, 'setState(...): Cannot call setState inside getChildContext()' );

You're right, Thanks

gaearon · 2016-02-28T12:51:34Z

This looks great to me! Let’s hear what @jimfb has to say.

raineroviir · 2016-02-28T19:30:06Z

I am failing a test locally not sure why it isn't failing in travis. Is that kinda worrying?

FAIL  src/renderers/shared/reconciler/__tests__/ReactCompositeComponent-test.js (3.028s)
● ReactCompositeComponent › it should pass context when re-rendered
  - Expected: 1 toBe: 0
        at Spec.eval (src/renderers/shared/reconciler/__tests__/ReactCompositeComponent-test.js:843:46)

facebook-github-bot · 2016-02-28T19:37:33Z

@raineroviir updated the pull request.

jimfb · 2016-02-29T17:43:48Z

src/isomorphic/ReactDebugTool.js

@@ -10,7 +10,7 @@
 */

 'use strict';
-
+var ReactInvalidSetStateWarningDevTool = require('./devtools/ReactInvalidSetStateWarningDevTool');


Normally we would just do require('ReactInvalidSetStateWarningDevTool'), so this seems weird. I'm assuming you did this because require('ReactInvalidSetStateWarningDevTool') didn't work for you because you didn't have an @providesModule at the top of that file.

If you add the standard copyright header to ReactInvalidSetStateWarningDevTool.js and specify the @providesModule, we should be able to fix this line.

Got it. That providesModule thing is super cool

jimfb · 2016-02-29T18:02:06Z

I looked into the failing unit test, it looks like a valid failure caused by this change (ie. needs to be fixed before we can merge). That test is not invoking setState() during getChildContext, but the warning appears to be firing.

I'm not sure why it didn't fail travis (cc @zpao).

facebook-github-bot · 2016-02-29T18:04:13Z

@raineroviir updated the pull request.

facebook-github-bot · 2016-03-01T05:08:03Z

@raineroviir updated the pull request.

jimfb · 2016-03-01T05:13:23Z

src/renderers/shared/reconciler/__tests__/ReactCompositeComponent-test.js

@@ -783,7 +812,7 @@ describe('ReactCompositeComponent', function() {

      render: function() {
        var output = <Child />;
-        if (!this.state.flag) {
+        if (this.state.flag) {


What is going on here? Why this change?

I wanted to see why the test was throwing the warning

in the original test we rendered <Parent> <Child /> <Parent>, and on setState we change the render to <Parent>Child</Parent>

in the changed test which doesn't create a warning we go from Child  to <Child />

I commited the change here for now in case it could benefit our search for the fix

Ok, well, we still need to fix so the original test passes.

Yeah! I will make the original test pass

jimfb · 2016-03-03T02:49:27Z

Ping @raineroviir

raineroviir · 2016-03-03T02:57:23Z

I've tried many things I'm not sure how to go about fixing the test.

raineroviir · 2016-03-04T22:55:16Z

Wow I spent so long on this problem. I looked at some awesome code that vslinko wrote to fix this issue and it was so simple, I just did not fully understand the issue I was fixing. I made an early assumption of where the code should go and tried everything to make it work. Sigh. Like trying to stick a square peg in a round hole

facebook-github-bot · 2016-03-04T22:55:55Z

@raineroviir updated the pull request.

gaearon · 2016-03-05T02:32:25Z

src/renderers/shared/reconciler/__tests__/ReactCompositeComponent-test.js

+    expect(instance.state.value).toBe(1);
+    expect(console.error.calls.length).toBe(1);
+    expect(console.error.argsForCall[0][0]).toBe(
+      'Warning: setState(...): Cannot call setState inside getChildContext()'


Nitpicking: let’s add () for consistency? As in Cannot call setState() inside getChildContext().

gaearon · 2016-03-05T02:33:49Z

The earlier problem was likely due to return later in the method which caused onEnd* to be missing. You fixed it correctly by wrapping just the getChildContext() call.

Great job! Thank you for following through with this.

gaearon · 2016-03-05T02:34:05Z

Would you mind squashing it as a single commit?

facebook-github-bot · 2016-03-05T06:46:48Z

@raineroviir updated the pull request.

facebook-github-bot · 2016-03-05T06:55:53Z

@raineroviir updated the pull request.

facebook-github-bot · 2016-03-05T07:22:38Z

@raineroviir updated the pull request.

raineroviir · 2016-03-05T07:24:19Z

I totally just squashed all those commits! Thanks for all the great comments guys, no better way to learn how to do this stuff than by doing

jimfb · 2016-03-05T16:23:21Z

This looks great to me, thanks @raineroviir!

Fix #6114 - Calling setState inside getChildContext should warn

facebook-github-bot added GH Review: review-needed CLA Signed labels Feb 25, 2016

jimfb reviewed Feb 25, 2016
View reviewed changes

jimfb reviewed Feb 27, 2016
View reviewed changes

This was referenced Feb 28, 2016

Warn if calling setState in getChildContext #6114

Closed

Warn when setState called within getChildContext #6135

Closed

gaearon reviewed Feb 28, 2016
View reviewed changes

jimfb reviewed Feb 29, 2016
View reviewed changes

jimfb mentioned this pull request Feb 29, 2016

Jest failed, Travis Passed #6150

Closed

jimfb reviewed Mar 1, 2016
View reviewed changes

jimfb mentioned this pull request Mar 3, 2016

createChainableTypeChecker suggests mistyped props by case #6173

Closed

raineroviir force-pushed the rainer branch from 1b8b939 to 754bbf9 Compare March 3, 2016 03:23

gaearon reviewed Mar 5, 2016
View reviewed changes

raineroviir force-pushed the rainer branch 2 times, most recently from 29f8ff4 to 3f2ffeb Compare March 5, 2016 06:46

raineroviir force-pushed the rainer branch from 3f2ffeb to 72e80df Compare March 5, 2016 06:55

Fix facebook#6114 - Calling setState inside getChildContext should warn

9c1916d

raineroviir force-pushed the rainer branch from 72e80df to 9c1916d Compare March 5, 2016 07:21

jimfb added GH Review: accepted and removed GH Review: review-needed labels Mar 5, 2016

jimfb added a commit that referenced this pull request Mar 5, 2016

Merge pull request #6121 from raineroviir/rainer

10f9476

Fix #6114 - Calling setState inside getChildContext should warn

jimfb merged commit 10f9476 into facebook:master Mar 5, 2016

gaearon mentioned this pull request Apr 28, 2016

Integrated warning on returning null #6636

Closed

2 tasks

renovate bot mentioned this pull request Feb 2, 2018

Update dependency react to v0.14.9 - autoclosed signavio/backbone-rel#29

Closed

1 task

Fix #6114 - Calling setState inside getChildContext should warn #6121

Fix #6114 - Calling setState inside getChildContext should warn #6121

Conversation

raineroviir commented Feb 25, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

facebook-github-bot commented Feb 27, 2016

Choose a reason for hiding this comment

facebook-github-bot commented Feb 27, 2016

facebook-github-bot commented Feb 27, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Feb 28, 2016

raineroviir commented Feb 28, 2016

facebook-github-bot commented Feb 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimfb commented Feb 29, 2016

facebook-github-bot commented Feb 29, 2016

facebook-github-bot commented Mar 1, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jimfb commented Mar 3, 2016

raineroviir commented Mar 3, 2016

raineroviir commented Mar 4, 2016

facebook-github-bot commented Mar 4, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Mar 5, 2016

gaearon commented Mar 5, 2016

facebook-github-bot commented Mar 5, 2016

facebook-github-bot commented Mar 5, 2016

facebook-github-bot commented Mar 5, 2016

raineroviir commented Mar 5, 2016

jimfb commented Mar 5, 2016