react-context-by-parent warning

[EvHaus]

I've been running into the following React warning when using react-dnd:

owner-based and parent-based contexts differ (values: `[object Object]` vs `undefined`) for key (dragDropManager) while mounting DropTarget(Card)

It happens anytime I render my DropTarget() component outside of the main React.Router, like in the case of a modal/dialog.

For modals, I create a new DOM node inside document.body and then call React.render(React.createElement(MyModalDialog)); and then I have draggable elements inside the dialog.

Can you help me understand what causes this warning and how I can make it go away?

[gaearon]

It means that, in React 0.14, your drop targets won't receive the context inside modal windows.

You can fix this by moving DragDropContext outside the router. I think React Router 1.0 (currently beta) defines <Router> as a component so this will be easy to do. You'll just wrap <Router> into your top-level component that has DragDropContext.

Until React 0.14 is out, you can ignore these warnings.

[gaearon]

For modals, I create a new DOM node inside document.body and then call React.render(React.createElement(MyModalDialog)); and then I have draggable elements inside the dialog.

We'll see how “portals” context works in 0.14. I don't know yet.. Maybe @jimfb can clarify.

[jimfb]

React.render() does not pass context, but if you are implementing "portals", you can use ReactWithAddons.renderSubtreeIntoContainer(parentComponent, elementToRender, container, callback), which behaves like React.render() except that (from a context perspective) the rendered tree behaves as-if it were a child of parentComponent, thus allowing portals. It is worth noting that the API for renderSubtreeIntoContainer may change slightly in the future (for instance, the way events propagate through it may change slightly), but the intended usecase is portals, so the behavior should remain "good" for that use case.

[gaearon]

@jimfb Thanks a lot for the explanation!

[slorber]

related to facebook/react#4081

[qimingweng]

@jimfb is renderSubtreeIntoContainer available in 0.13.3? If so, how can I access it, require('react/addons') doesn't seem to produce an object that has this function (at any depth)

[slorber]

@qimingweng no it is in 0.14.0-beta1

See facebook/react#4301

It seems as the API may change, you can access it like that:

var renderSubtreeIntoContainer = require("react-dom").unstable_renderSubtreeIntoContainer;

[qimingweng]

Thanks @slorber (with there was a way to like a comment or something on github, lol)

[epferrari]

@slorber, I've been coming up against this as well. It should be explicitly noted for anyone who finds this discussion that even if you require renderSubtreeIntoContainer into your 0.13.3 project, it's not going to work because of the missing React internal methods it calls, like parentComponent._reactInternalInstance._processChildContext(), a new method of ReactCompositeComponentWrapper. I assume that's what your reply to @qimingweng was saying, but it was a little ambiguous the first time I read it, so this is for anyone else who might misinterpret as. "it's not in 13.3 but you can require it like this: .... "

You can certainly require it. But it won't work unless you are on 0.14 beta. However, I have a workaround gist that provides a solution for 0.13 users who would rather not use NODE_ENV=production or attempt to rewrite console.warn to ignore that specific warning.

[slorber]

@epferrari the react-dom package is new and coming for 0.14 release.

Obviously you should not use that package with a version lower than 0.14 :)

[epferrari]

yes, got it thanks :)

As for the mitigating the warnings about owner context vs. parent context in 0.13, what's working well for me at the moment is passing context on a wrapper to nested components on the other side of the portal. Hopefully someone can benefit from that without trying to rewrite console.warn, as I have seen proposed by several people in the community. Best not to do that.

[slorber]

yes @epferrari the wrapper to forward context works but people probably need the parent to pass context to the portal, instead of writing hardcoded context values.

I've implemented something similar here: https://github.com/stample/atom-react/blob/master/src/atomReactContext.js#L326

function ChildContextProviderFactory(context) {

    // TODO we are very permissive on the childContextTypes (is it a good idea?)
    var childContextTypes = {};
    _.keys(context).forEach(function(contextKey) {
        childContextTypes[contextKey] = React.PropTypes.any.isRequired
    });

    return React.createFactory(React.createClass({
        displayName: "ChildContextProvider",
        childContextTypes: childContextTypes,
        propTypes: {
            componentProvider: React.PropTypes.func.isRequired,
            context: React.PropTypes.object.isRequired
        },
        getChildContext: function() {
            return this.props.context;
        },
        render: function() {
            // TODO simplify this "componentProvider hack" after React 0.14? See https://github.com/facebook/react/issues/3392
            var children = this.props.componentProvider();
            return children;
        }
    }));
}