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
Support for dynamic routes #243
Comments
We believe that you should declare all your routes up front, and then validate the visitor's ability to visit them like the I'm sure you could setup/teardown some initial routes, make your decision, and then render some new ones though. |
@rpflorence Do you have a recommendation for the following use case?
I could change it to this -
but then the Thanks for the help! |
<Route handler={App}>
<Route name="session-user-page" path={"/" + sessionUser.name} handler={SessionUserPage}/>
<Route name="public-user-page" path="/:userName" handler={PublicUserPage}/>
</Route> That will work fine, as long as you always have a value in I'd personally rather have one route and check a session store to branch in
Not sure I understand why you think this is the case. Any component can talk to a session store without passing it down through props. var moduleThatKnowsTheSession = require('../stores/session');
var UserPage = React.createClass({
// some code to get state from the module that knows the session
render: function() {
if (!this.state.session.loggedIn) {
return <PublicUser/>
} else {
return <SessionUser/>
}
}
});
module.exports = UserPage; |
The problem I ran into with that bit of code not working is that props are only resolved the first render (as shown in the jsfiddle), so passing the I assumed that passing the |
If your session data is going to change, then yeah, that won't work.
Finally, server apps don't have dynamic routes, not sure why we'd expect a client app to. |
Makes sense - thanks for the help! It looks like my problem with the nested listeners is due to the inability to remove listeners during an emit call in node's
|
Yeah, that's how I do it :) |
@rpflorence I was wondering if you would have any suggestions for creating Routers that are based off of other files that are required at runtime? I'm working on a project which will be a platform that future developers will create plugins to run on, so they need to be able to create their React components, and then register them with the Router. This makes it so there won't be an opportunity for us to declare all routes up front, as you mentioned earlier. My current thought process is that each component that will be providing a Route "registers" into an object and then we iterate over those registers routes when creating the object. Unfortunately I haven't had any luck so far. Any suggestions? |
you can "export" some routes from a plugin maybe? <Routes>
{SomePlugin.routes()}
</Routes> |
@zackfern any luck on your problem? I also need to implement some similar solution for a plugin system and I am also struggling with the setup. If you could shred some light or if you found some solution it would be awesome, thanks ;) |
hey :) i'd like to handle infinite nested states in my app, for example i open a "card" and another one can open inside it, and on and on, on-demand. technology > javascript > web > css... any idea how to implement this in a clean way ? |
@zackfern have you got a solution on your problem? I have the similar problem, thanks |
use a wild-card path, and then parse it yourself. this.props.params.splat And then nest the Card view over and over for your parsed path. On Tue, May 19, 2015 at 10:20 AM, pawawat notifications@github.com wrote:
|
@pawawat I ended up creating my own registration system for registration into the routes. When it came time to generate the Route JSX I looped over my registration array and generated the Route object on the fly. |
@zackfern any code sample ? |
I'm in a weird spot where I'd love support for this, but only so that we can phase it out little by little in the existing application. We're using backbone routes, with subroutes being dynamically added when a route is loaded--which is super gross. I'm pushing for moving to react-router, but having to migrate all at once makes the task a lot more imposing. |
I too have this issue where my routes are stored in an immutable map. Even converting the map to an array, react-router still does not resolve the routes. ReactDOM.render(
<Router history={history}>
{state.pages.toSeq().toArray().map((item) =>
<Route
key={item.get('route')}
path={item.get('route')}
component={require(item.get('component'))} />
)}
</Router>
, target
); I think that using the "*" route and doing our own custom parsing will work for us in the short-term, but another solution would be better. Any help appreciated. |
any update on @bishopZ code? i also can't do the dynamic routes with |
Adding dynamic routes using Use case: I'm building a quiz app where each question gets a route (on client), and users can add questions (by pushing an object into an array), thereby (in a perfect world) adding routes to access those questions, via What are the drawbacks I'm not seeing? Would this be difficult to implement? |
Dynamic routes would be also very helpful when loading async modules that also have some routes. |
Dynamic routes are supported for the async case. You just can't change your root route ATM. |
I had a problem while trying to generate routes based on my state. I'm dumping that here in case someone stumble upon this post like I did earlier. const routes = [
this.state.routes.map(
route => {
{
path: route.path,
component: route.component,
}
}
)
] and later when you declare your router: <Router routes={routes} history={browserHistory} /> from the docs |
Is dynamically creating routes based on application state a supported or planned feature? This jsfiddle shows an example of props being resolved only the first time. Perhaps there's a better pattern I haven't found.
The use case I'm after is explained in the docs for react-router-component, which supports dynamic routes:
The text was updated successfully, but these errors were encountered: