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
Extracting Sub-Routers to separate component. #15
Comments
Not right now. I personally really like seeing all of the routes for an app in one place. What is the value in having your routes defined all over the application? On Sat, May 31, 2014 at 9:00 AM, Matt Aitchison notifications@github.com
|
Note the partial app loading example, you only need a tiny handler for each On Sun, Jun 1, 2014 at 7:47 AM, Ryan Florence rpflorence@gmail.com wrote:
|
It would allow me have completely isolated components. Say I have a User module that will have the following views. Edit, List, Then if you go to I hope that makes sense.
|
How is it helpful to have the route definition away from the rest of the Your components are still isolated, the route definitions simply bring them You can also write a static function on User that returns the routes you <Routes>
{User.routes()}
{Dashboard.routes()}
</Routes> When you consider a server-side app, do you define your routes in multiple places? |
Well you could have more than 40 routes on certain apps and that would be a I feel that defining every route in one place breaks the isolation that Yeah I was thinking about that but I couldn't think of how to do it. I Thanks!
|
Your components are still isolated. Routes are not components, they are simply config objects stripped of their properties to explain the relationship between components. You have to define the relationship between components eventually. Doing what you proposed up top or what I think is best practice doesn't make anything more or less isolated, its simply a matter of how many steps until you find the configuration. I've worked on an ember app with 60+ routes, it was absolutely fantastic to be able to see how the application was stitched together. Consider getting a bug report with the url of You can either bounce around your app trying to find where that route is configured or you can go to a single place and see which handler you need to look at immediately. |
@MattAitchison FWIW I originally thought about this issue the same way you are but have since been swayed by @rpflorence's (and Ember's) thinking on this. The router does nothing to couple your components. If anything, it keeps them more cleanly separated by only requiring you to use I'm closing this for now. Will gladly reopen if/when we have a convincing use case. |
@mjackson Yes but defining every route in a single spot does couple things. Now the only way your 'files' component can /edit /delete or anything else is by adding all of it's routes multiple times in the Main apps render method. |
@MattAitchison What do you mean multiple times? Might be relevant, we do need to add the *wildcard so you can have something like a mock filesystem: <Routes>
<Route name="file" path="files/*" handler={File}
</Routes> And that would allow for any routes at |
Something like the following would be nice to implement. https://github.com/andreypopp/rrouter/blob/master/lib/__tests__/matchRoutes-test.js#L233-L249 |
I still don't get it. Why couple your components together by having route definitions in the components? And what do you mean "adding all of its routes multiple times in the Main apps render method"? |
I think I have an interesting use case for this. I have a website where users get their own '/mypage' type thing. Depending on what they've configured they may wish to serve up a different react application. e.g. they may have ticked 'portfolio' which means a portfolio react app will be served up, or they may have ticked 'blog' which means a blog react app should be served up. I currently have this code on my router but I can't see how I can accomplish my sub react apps to have their own router definitions.
|
This is totally server-side no? You'd just serve two entirely separate apps. Or use the async routes stuff to only load the one you need. |
It's server and client. I've been using this starter kit which seems to handle routing totally different with a method like below.
After your comment I've been reading all the tutorials on async routes. Looks like what I'm asking is completely possible, but I can't see how it fits in with the method used above. I've asked a more relevant question over on the react starter kit repo though. Cheers. |
The huge-apps example is a good one to demonstrate were routes in separate files makes sense. |
I totally agree. I'm building an application which is basically an administration system for whatever modules I might build (custom CMS anybody? ;) ), when I install a certain module I might, or might not want a section for that specific module, and it would be awesome to be able to route that from its own isolated environment without having to generate code that does that for me. But maybe async and dynamically load the needed routes and whatnot is the way to go? |
Compartmentalizing routes with the corresponding components is very analogous to what a lot of express middleware do where internally they define a Also compartmentalizing need not mean coupling. If you can require then mount the set of routes, there is no reason you couldn't require each component independently if you wanted to and wire them up however you wanted. |
The problem on the client side is that, with the way React mounts components, using nested components and React lifecycle hooks for data fetching will lead to waterfalled requests. As a different pattern, we support highly compartmentalized route configs. This lets you isolate specific portions of your application (and embed them as sub-applications on specific paths), while not losing the benefits of top-level routing. |
(see e.g. the huge-apps example to see how this works in practice) |
Is there any way to do the following?
Main
Profile
Explore
I would like to do this to separate my app out so i don't have to include every component/route in the Main handler.
The text was updated successfully, but these errors were encountered: