Skip to content

Navigation Mixing Failed Context Propagation #400

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

Closed
CalebMorris opened this issue Oct 13, 2014 · 16 comments
Closed

Navigation Mixing Failed Context Propagation #400

CalebMorris opened this issue Oct 13, 2014 · 16 comments

Comments

@CalebMorris
Copy link

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
Copy link
Contributor

gaearon commented Oct 14, 2014

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
Copy link
Author

@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
Copy link
Contributor

gaearon commented Oct 14, 2014

Can you try to isolate your failing case?

@gaearon
Copy link
Contributor

gaearon commented Oct 16, 2014

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

@mjackson
Copy link
Member

@gaearon Could cloneWithProps be the culprit?

@gaearon
Copy link
Contributor

gaearon commented Oct 16, 2014

@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
Copy link
Contributor

abergs commented Oct 20, 2014

I am having this problem as well:

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

@mosch
Copy link
Contributor

mosch commented Oct 21, 2014

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
Copy link

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

@gaearon
Copy link
Contributor

gaearon commented Dec 16, 2014

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
Copy link

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
Copy link

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

@gaearon
Copy link
Contributor

gaearon commented Dec 18, 2014

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
Copy link

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

@ryanflorence
Copy link
Member

I'm just pruning the issues, this appears to have been solved/worked around? If not, please holler.

@tjwebb
Copy link

tjwebb commented Mar 5, 2015

I am seeing all kinds of Context problems using cloneWithProps. Is there a way to make cloneWithProps work nicely with RR?

@lock lock bot locked as resolved and limited conversation to collaborators Jan 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants