-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
Comments
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?
? |
@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. Would having the component not be part of the active route influence the context being passed? |
Can you try to isolate your failing case? |
Ouch! I also have |
@gaearon Could |
@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. |
I am having this problem as well: Invariant Violation: TopBar.getChildContext(): key "makePath" is not defined in childContextTypes. |
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… |
Did anyone find a workaround for this? Or at least a way to use transitionTo without having to use the Mixin? |
You can export |
With flux, same issue happens when a component with Any workarounds for that, or how can it be fixed? |
Ok, upon further exploration, the context gets lost when a component is passed to state via |
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 |
@gaearon I also arrived to the same conclusion and refactored accordingly. Thanks! |
I'm just pruning the issues, this appears to have been solved/worked around? If not, please holler. |
I am seeing all kinds of Context problems using |
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.
The text was updated successfully, but these errors were encountered: