New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with unstable_renderSubtreeIntoContainer and refs #9808

Closed
cassln opened this Issue May 29, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@cassln
Copy link

cassln commented May 29, 2017

Do you want to request a feature or report a bug?
Report a bug.

What is the current behavior?
I use the usual technique of portals with unstable_renderSubtreeIntoContainer. Also I need to control portal children with refs (using legacy syntax I know).

The problem is unstable_renderSubtreeIntoContainer is async and can be called after componentDidUpdate. When refs are used in componentDidUpdate, they can be undefined due to async nature of unstable_renderSubtreeIntoContainer.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/84v837e9/).
Demo. Open the browser console and press "add" button. You will got this error:

Uncaught TypeError: Cannot read property 'getBoundingClientRect' of undefined
    at App.componentDidUpdate (<anonymous>:33:64)
    at measureLifeCyclePerf (react-dom.js:4581)
    at react-dom.js:5235
    at CallbackQueue.notifyAll (react-dom.js:948)
    at ReactReconcileTransaction.close (react-dom.js:11454)
    at ReactReconcileTransaction.closeAll (react-dom.js:14882)
    at ReactReconcileTransaction.perform (react-dom.js:14829)
    at ReactUpdatesFlushTransaction.perform (react-dom.js:14816)
    at ReactUpdatesFlushTransaction.perform (react-dom.js:12936)
    at Object.flushBatchedUpdates (react-dom.js:13019)

It causes because of, according to logs

componentDidUpdate
complete unstable_renderSubtreeIntoContainer

componentDidUpdate called before unstable_renderSubtreeIntoContainer callback.

What is the expected behavior?
Are needed defined refs in componentDidUpdate. In the general case, a completely completed render.

I know about pattern with using unstable_renderSubtreeIntoContainer callback, but this is not preferred solution. Because of I have quite complex combination of two libraries and don't have access to unstable_renderSubtreeIntoContainer callback. If someone is interested in libs, this is react-autocomplete and react-tether.

There may be a way with avoiding rerender and saving the refs from the first render?

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
I'm using v15.4.2.

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Jun 13, 2017

It's a bit hard for me to figure out what's going on there, but in any case we're going to eventually drop unstable_renderSubtreeIntoContainer in favor of a first-class portal API.

You can see a working example using unstable_createPortal here: https://jsfiddle.net/r442t0mk/. (It requires React 16 which is in alpha now.)

I'll close because it's unlikely we'll change unstable_renderSubtreeIntoContainer behavior, but I hope this helps.

@gaearon gaearon closed this Jun 13, 2017

@oliviertassinari

This comment has been minimized.

Copy link
Contributor

oliviertassinari commented Jun 13, 2017

@gaearon Thanks for the following up. We will try to refactor the portal implementation (using unstable_createPortal) of Material-UI to solve that regression introduced by the fiber reconciliation algo.

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Jun 13, 2017

I don't think there is any regression there, is there? It seems like the example in this issue is with 15.4.x. So Fiber does not change the behavior there.

@oliviertassinari

This comment has been minimized.

Copy link
Contributor

oliviertassinari commented Jun 13, 2017

I'm not sure it's a regression either, it could be an edge case making it work with 15.4.x but not with the pre-release version. Still, we have noticed a breaking-change on the Material-UI project. We have that open issue for more reference mui-org/material-ui#7025. Will dig more into it.

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Jun 13, 2017

I’m still confused. Are you saying there is a React version where https://jsfiddle.net/cassln/cusus029/2/ (which uses 15.4, not Fiber) ever worked? Or are you saying there is a different similar issue?

@oliviertassinari

This comment has been minimized.

Copy link
Contributor

oliviertassinari commented Jun 21, 2017

I have managed to reproduce what we experience with a simple jsfiddle demo. mui-org/material-ui#7025 (comment) The behaviour definitely changed between latest (v15.6.1) and next (16.0.0-alpha.13). However, that's most likely not important as affecting a unstable API that is going to have a first class one on the fiber version. @gaearon Thanks for the support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment