Navigation Mixing Failed Context Propagation

[CalebMorris]

I am attempting to use the updated React-Router (0.9.2) with a website I am working on with React.
When using the mixin for a non-child component (A component that is loaded when an event is emitted in a different portion of the application) the context doesn't seem to propagate as expected and non of the mixin methods are usable.

Example log : Warning: Required context 'makePath' was not specified in 'MyThing'.

Looking at the React blog
http://facebook.github.io/react/blog/2014/02/20/react-v0.9.html#breaking-changes
I noticed the final element no longer allows using this.context as it is reserved for internals.

I'm not sure if this is directly related as I don't understand quite what you are doing in the mixin.

Am I misunderstanding the usage of this mixin?
Is there a workaround to pass the context to a component by one that doesn't own it?

Example Code:
Component that uses mixin.

var BS     = require('react-bootstrap');
var React  = require('react');
var Router = require('react-router');

React.createClass({
  displayName : 'MyThing',
  mixins : [ Router.Navigation ],
  goToPlace : function() {
    this.transitionTo('path', null, {
      preQual    : true,
      propertyId : this.props.propertyId,
    });
  },
  render : function() {
    return (
     <div>
        <BS.Button onClick={this.goToPlace}>
          Go There Now
        </BS.Button>
      </div>
    );
  }
});

[gaearon]

I agree context is deemed dangerous and although it solves RR's problems nicely, it may cause problems for end users.

Could any of these problems be the one you're describing?

Context is only passed to children that are rendered within the render() method. Here's an example of how context gets lost. And cloneWithProps() doesn't copy context or owner. This is problematic since lots of React-based repos use it. For example when using ModalTrigger in react-bootstrap, the context doesn't get passed to the Modal components.

?

[CalebMorris]

@gaearon I'm not sure if this is quite the reason. I'm adding a little more information to maybe help see where I am losing the context.

I have a wrapper class which renders 2 components.
The first is a component that displays information that changes on a dispatcher event.
The second is the activeRoute component and is the main interaction point that sends the dispatcher events to trigger the first.
The context to use the Navigation mixin is passed to the second component, but not the first.

Would having the component not be part of the active route influence the context being passed?

[gaearon]

Can you try to isolate your failing case?

[gaearon]

Ouch! I also have <Link>s inside modals failing to receive their context in my project.

[mjackson]

@gaearon Could cloneWithProps be the culprit?

[gaearon]

@mjackson For me, seemingly not. Rather a certain component doing a round-trip from event handler -> to some JS -> later resurfacing as a prop. I know it was a bad idea anyway though so not a huge issue in this case.

[abergs]

I am having this problem as well:

Invariant Violation: TopBar.getChildContext(): key "makePath" is not defined in childContextTypes.

[mosch]

Same problem here. Usage in a Modal fails, it's not possible for the mixin to get the context, all functions are "null". Also in some other cases where i maybe could try to cloneWithProps() but doesnt look to clean to me. Need to stick to version 0.7 for now…

[radiosilence]

Did anyone find a workaround for this? Or at least a way to use transitionTo without having to use the Mixin?

[gaearon]

Or at least a way to use transitionTo without having to use the Mixin?

You can export router separately and call it from anywhere: https://github.com/rackt/react-router/blob/master/docs/guides/flux.md

[hakanderyal]

With flux, same issue happens when a component with <Link> inside follows the action -> store -> store.onChange -> component -> render from prop path.

Any workarounds for that, or how can it be fixed?

[hakanderyal]

Ok, upon further exploration, the context gets lost when a component is passed to state via this.setState and later retrieved from state.

[gaearon]

With flux, same issue happens when a component with inside follows the action -> store -> store.onChange -> component -> render from prop path.

Actually I think passing components in Flux isn't a good idea (although it can be tempting). This makes payload unserializable so you lose potential record/playback benefits.

Instead, I usually serialize data and, if needed, make enums with types of components I might want to render dynamically, that I later switch upon in render.

[hakanderyal]

@gaearon I also arrived to the same conclusion and refactored accordingly. Thanks!