TypeError: Cannot read property '_currentElement' of null

[korakon]

From maintainers: if you have this problem, please see the explanation in #6895 (comment).

Test case: jsFiddle

The error is in this function, internalInstance is null.

  /**
   * Releases any resources allocated by `mountComponent`.
   *
   * @final
   * @internal
   */

  unmountComponent: function(internalInstance) {
    ReactRef.detachRefs(internalInstance, internalInstance._currentElement);
    internalInstance.unmountComponent();
  }

I managed to "fix" the bug by simply checking if internal state is not null but that requires modifying react.
Other mentions of this bug are listed below.

• http://stackoverflow.com/questions/29786154/upgrading-react-to-0-13-2-causes-uncaught-typeerror-cannot-read-property-cu
• Uncaught TypeError: Cannot read property '_currentElement' of null JedWatson/react-select#128
• Loading React more than once is causing context issues w/ react-router.  milankinen/livereactload#8
• https://gist.github.com/jamesknelson/1481521444e1529d59aa

[syranide]

Some invariant violations leaves React in an unstable state at the moment so this is to be expected. AFAIK this is partly because catching and re-throwing errors is a crapshoot in many browsers and may also have significant performance impact on hot code-paths.

[korakon]

Some invariant violations leaves React in an unstable state at the moment so this is to be expected ...
AFAIK this is partly because catching and re-throwing errors is a crapshoot in many browsers

I am rethrowing the errors in the test case because it is easier to demonstrate that way, in an application I am developing, the error happens even when I am not re-throwing any errors, Here is an example.

The function I am using is something like this, it simply switches pages,
go(UserPage({user: {name: 'k'}) or shows an error page if an error happened.

function go(page) {
    try {
         React.render(App(null, page), mount);
    catch (e) {
         React.render(App(null, ErrorPage({error: e})), mount);
    }
}

Test case

Is there any way to manually clear the state besides removing and reinserting the dom element?
I tried React.unmountComponentAtNode() but it throws the same error.

[JohnyDays]

Perhaps have a higher level component AppWrapper, that contains that state? or pass page/ErrorPage as props, and do setProps on App (your top-level component)

[syranide]

@korakon It doesn't matter if you rethrow errors, my intended point was that React can internally catch and rethrow errors to avoid the internal state breaking (completely at least) but doesn't because there are undesirable side-effects in many browsers currently.

AFAIK there is no clean way out of an invariation violation once it has happened. If you have a particularily vulnerable piece of code then wrap that in a try-catch, not the calls to React.

[korakon]

@JohnyDays
Thank you, I will be using this.

@syranide
Yeah, I get your point know, Thank you.

[blairanderson]

I am seeing this quite a bit, but very little headway towards finding the root cause.

on my local environment i can reproduce by adding an undefined variable into a function that changes the state of a component.

it throws as undefined, then all other attempts to render on the parent node fail with TypeError: Cannot read property '_currentElement' of null...

Is there a cool way to track stuff like this, given a giant component with a massive combinations of child components and states?

[JohnyDays]

This usually happens if you interrupt react's rendering cycle with an exception, you should take care not to do so, and you can usually catch them easily during dev. I have never had this happen in prod, so perhaps it's related to some dev-only cycle

[blairanderson]

@JohnyDays that makes sense.

Is there a way to force an unmount? I can't find any part of the api to do this.

Current solution is a try/catch around render(which sometimes throws while unmounting) then in catch replacing the element with a new one and rendering on the new element.

I'd like to have componentWillUnmount run for the components being unmounted(with force) and all its children before i remove the reference.

Can you think of any way to do this?

[jordancardwell]

@blairanderson FWIW, I recently found some sneaky regressions after migrating an app from 0.13 to 0.14.

After a lot of headache, I realized someone was mutating child props like

this.props.children[0].props.className = 'hidden'

This was hard to pinpoint, since the error didn't really point in any particular direction.

It was, however, easily fixed, once I found it by replacing with

var childrenWithNewProps = React.Children.map(this.props.children, function(child) {
  return React.cloneElement(child, { className: 'hidden' });
});

hopefully someone will find this helpful moving forward

[jimfb]

@jordancardwell You should have gotten a warning for that in dev mode with React 0.13. We try to warn in the previous version whenever making breaking changes, such that if you fix all your warnings then the migration to the next version will go smoothly.

[jordancardwell]

@jimfb yeah, that's is actually something react is really good at, and has made migrating to new versions pretty pleasant for the most part.

I definitely missed a deep dark corner of the app when clearing up warnings before this update.

That said, for cases when this happens, a more specific/descriptive error could be really helpful.

Maybe (optionally) logging a dump describing the unexpected variation, when in dev mode(?).. anything to prevent a dev from iterating through rounds of commenting out components and chunks of render methods to pinpoint where the 'bad thing' happened, and what flavor of 'bad thing' it was. (in my case, directly mutating child props)

Being familiar with React internals, you probably have a better idea of how feasible this is.

[jimfb]

@jordancardwell We did exactly that in 0.13.

Example text of error message:

Warning: Don't set .props.myFooProp of the React component <FooComponent />. Instead, specify the correct value when initially creating the element or use React.cloneElement to make a new element with updated props.

[jordancardwell]

@jimfb Right, I'm familiar with the warning messages about deprecations and breaking changes in future versions in React, and as I stated in the previous comment:

I definitely missed a deep dark corner of the app when clearing up warnings before this update.

I missed this particular warning in one area of our app before updating, but had corrected for the rest of the warnings that were thrown.

I was referring to the error message when something in your app causes an invariant violation in the current version (whatever it may be at the time). Some contextual information to point you in the right direction would be pretty valuable for anyone finding themselves in my situation.

React has always been extremely helpful with error messages and documentation around common errors. My comment about the feasibility of providing more information around invariant violations is to help in the situation where you've unwittingly done something stupid to cause it or failed to update something before a migration.

[jordancardwell]

So I supposed your point was that it's clearly feasible to do.. would it make sense to leave those descriptive messages in when people shoot foot-guns in dev mode.

So though it can still be a breaking change, the dev can get some helpful info.. you did this and it blew things up, we stopped allowing this in 0.13. get with the program.