-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Passing props to activeRoute #59
Comments
We had a feature where you'd get the ActiveRoute class in addition to the activeRoute descriptor. Maybe we should bring it back? While discussing it's removal we opted to encourage the use of stores. (the auth example eventually uses localstorage, but the handler uses the store.) Sent from my iPhone
|
This is mentioned in #30 but the idea of adding this capability wasn't followed up. It does seem strange to call for a component to be rendered and not have a way to pass in props. I expected to be able to say something like:
That specific syntax might be problematic. Also, the usefulness of this might not be as great as one would first think since you don't really know which component is going to be rendered in the above example. Using the Flux methodology, state like "logged in" should probably reside in a Store that you can check whenever you need to. |
You also have to remember to pass in the props the router creates for you, like params and query.
This is exactly what we talked about when we removed ActiveRoute. These route handlers should make every attempt to be independent entry points to your app; depending on props from a parent limit their portability/isolation. For example, if your user profile is nested inside some UI but you change the design and remove the nesting, you simply move the route in your route config and the app still works. I still kinda like getting the ActiveRoute descriptor though... Sent from my iPhone
|
+1 for getting the route descriptor. Seems like it would be useful for rendering navigation devices. |
Or maybe this.props.renderActiveChild(extraProps) Then we can still ensure you get the props the router sets up. Sent from my iPhone
|
if the fn |
That's how I imagine it working. My hesitancy is that now your routes are getting coupled to their view hierarchy, which is something I'd like to avoid. Also, timing of when things are created is out of the routers control, which might expose problems I can't think about right now. Sent from my iPhone
|
This is the big issue for me as well. I agree that And BTW,
I don't see any problems here that we couldn't work around. We would probably need to figure out a different way to get a handle on components for |
I think i'd appreciate having a In terms of flux, I prefer passing props parent -> child over having each view watch the store for its piece of state. In practice this does lead to a bit cruft with passing state down to children that the parent doesn't use directly, but even there we've found that the little extra redundancy is worth it for clarity of data flow through the views. It also means that each view is not tightly bound to a store. As an aside, while children views may have many different parents (reusable!), views with children almost always have the same children, in that regard it seems silly to say that the parent view doesn't use the state. Even if it passing it directly through to a child it does use it, it uses for a child view which is an integral and defining part of the itself. For us the usefulness of React is in its easy-to-reason-about-ness and a big part of that in our complex apps (react or not) have always declarative, easy to intuit api surfaces for component pieces. In React that generally means props, and propType validations |
I think the difference here is that a route handler is an entry point to your app and should be able to function as the root route or a deeply nested one. Before dismissing this idea as "not fluxy", think about your route handlers as something different than the view they render. var UserHandler = React.createClass({
// this class deals with being a route
render: function() {
// User deals with the view, and is passed props like you want it to
return User(someProps);
}
}); Just a thought. I still like (I just don't see myself using it because I know how often in ember I've moved my route config around to change view nesting and then cursed the nested assumptions in the rest of the code.) |
that's a fair point, I don't think that each route being independent is 'not fluxy' but I do think that routes don't always need that flexibility. It seems like some nested routes don't make sense outside their resource, or nested resource? I feel a little odd about the to the point of the
then we can just use it like any other component, do nothing to get the same behavior, or add in extra props. I assume that might mess with the transition hooks? |
Yes, that's it. It doesn't make any sense to pass custom props into a route handler because it should be able to function without a parent component.
|
Nah, that's different, though there's some overlap because route props get moved to their handlers. The original analogy was If you have more ideas, please share. At the moment I'm still liking |
That's how I feel too, but I'm also aware that people are happy to couple their routes together. React apps start with passing the props down and data back up, if we don't allow this flexibility then we are enforcing a bigger concept (stores) right out of the gate. This is right on my flexibility v. enforced-good-practice line. |
ok, I can agree with that. If we're going this route, I'd like to use the Also, I have no idea what people would be using the |
that is true, hmm.
I can see how that might be an issue, although, does that not make sense in plenty of cases? Perhaps i am missing some of the philosophical background on why a route would always want to be like that? I feel like practically we end up having plenty of routes that don't/shouldn't work without a parent component. specifically in master/detail sorts of situations. for instance a page with a list of artists side panel and a detail
this sort of nails my thought process about the whole thing (it appeared as I was writing :P) |
Guys, does this mean that this gist isn't actually a bug? I've noticed that props do get password to the handler at first, but don't change on state change. https://gist.github.com/joecritch/586a6868874c99fa92eb |
@joecritch You shouldn't put |
I would be curious to know how FaceBook has chosen to do this. They clearly make a big a deal about props, @BinaryMuse's Fluxxor has mixin support for them, etc. I'm not convinced there has to be ambiguity around this issue with n relatively equal approaches. If the problem space of the app is well defined there ought to be a functional composing declarative immutable etc. pattern that clearly stands out. On that note I would also put stock into any work the clojure community has done on these issues by way of Om https://github.com/swannodette/om. Edit: https://github.com/swannodette/om#does-om-provide-routing |
I've been thinking about this a lot and I think we should do it. Or ... if we could swing this API (not sure we can), then it would feel even more react idiomatic, reacomatic, idioreactic, ridiomactic?): var SomeHandler = React.createClass({
render: function() {
return (
<div>
<h1>Welcome</h1>
<ActiveRoute/>
</div>
);
}
}); |
I pushed a branch to get us started with |
Yeah but ... that's a lovely, lovely API. Maybe we can get @petehunt and co. to bless our shenanigans. Awesome work :) |
Is it possible for a route handler to pass props to its child route handler? Currently I do this for setting/getting signed in state and opening modal dialogs, among other things. I notice that the auth example depends on localStorage instead. Is it necessary to externalize things from the app state like this to make them accessible from nested route handlers?
The text was updated successfully, but these errors were encountered: