Just wondering about the use of .map there. Does the mapper actually somehow use the result of each call, so that it becomes important to use .map, or is the important part more of a side-effect, so that .each would do? If the latter, I think that would be clearer as it wouldn't raise this question, in the minds of those of us who tend to overthink things. :-)
However, I would assume that if it is loading the route partials, it would add some kind of overhead. That being said, I would also argue that the overhead would be minimal. Given the number of controllers that gitlab uses and its performance that i've experienced, any kind of overhead would be worth the added maintainability.
Also, I think that this would just be a valid point on a development environment. By default, if you were to change routes in production, you would have to restart the application to pick up the changes.
Putting the sub_path as a param after the name seems slightly confusing to me. When I want to know "where" the file is, it's easier to see "sub_path/filename". Just a thought! I found this episode very helpful.
The code will start to get messy. You wouldn't be able to simply extract out the routes into another file. You would have to still use the Rails.application.routes.draw, but then would also need to figure out how to not overwrite what you've already required. The method that I've demonstrated in this episode was fairly unobtrusive.
You can simplify your draw method to not branch out on subpath. Pathname#join accepts multiple arguments and if one of them is empty string, then it will not be included in created path:
Just wondering about the use of .map there. Does the mapper actually somehow use the result of each call, so that it becomes important to use .map, or is the important part more of a side-effect, so that .each would do? If the latter, I think that would be clearer as it wouldn't raise this question, in the minds of those of us who tend to overthink things. :-)
Either should work since the method is calling instance_eval.
Does this slow down your app? Are those partials loaded at every request?
Honestly, I've not done any benchmarking.
However, I would assume that if it is loading the route partials, it would add some kind of overhead. That being said, I would also argue that the overhead would be minimal. Given the number of controllers that gitlab uses and its performance that i've experienced, any kind of overhead would be worth the added maintainability.
Also, I think that this would just be a valid point on a development environment. By default, if you were to change routes in production, you would have to restart the application to pick up the changes.
Got it, thanks for your comment! Implementing it now :)
I have a massive routes file on an app I'm working on right now, and it has several namespaced sections, so this episode was just at the right time!
One thought, though.
Instead of: draw :filename, "sub_path", why not use: draw "sub_path/filename" ?
Putting the sub_path as a param after the name seems slightly confusing to me. When I want to know "where" the file is, it's easier to see "sub_path/filename". Just a thought! I found this episode very helpful.
In hindsight, you're right. Either way should work with the latter being more clear.
Nice idea of splitting large route files.
But am i misunderstanding something or could you just as well use require_relative , either directly or instead of the instance_eval ?
The code will start to get messy. You wouldn't be able to simply extract out the routes into another file. You would have to still use the Rails.application.routes.draw, but then would also need to figure out how to not overwrite what you've already required. The method that I've demonstrated in this episode was fairly unobtrusive.
You could however, do something like this
And it would probably have a similar effect, however, I don't think that it is as 'clean'.
Hi.
You can simplify your draw method to not branch out on subpath. Pathname#join accepts multiple arguments and if one of them is empty string, then it will not be included in created path: