public
Last active

  • Download Gist
gistfile1.rb
Ruby
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
class ActionDispatch::Routing::Mapper
def draw(routes_name)
instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb")))
end
end
 
BCX::Application.routes.draw do
draw :api
draw :account
draw :session
draw :people_and_groups
draw :projects
draw :calendars
draw :legacy_slugs
draw :ensembles_and_buckets
draw :globals
draw :monitoring
draw :mail_attachments
draw :message_preview
draw :misc
 
root to: 'projects#index'
end

Why do you need to use instance_eval here?

@mrcasais, because then the config/routes/x.rb files do not need any wrapping, they can just use the route syntax directly.

That's really clever, thanks for sharing! :)

Nice organizational refactor.

This reminds me of something that I like in Django where you have a root URL conf and then separate URL confs in each 'app' which get mixed in. Great for organization. Likey.

We'll get this into rails/master shortly as well.

Why do you use Rails.root.join to get absolute path before reading it? Since rails application is always started from application folder, relative path should suffice, no?

Another note on Rails.root: since it's a Pathname, you can do: Rails.root.join("config/routes/#{routes_name}.rb").read

this is called "put the trash under the carpet" lol, lines are still there

Only if you consider your routes to be trash. I consider them to be gold. I like my gold neatly sorted in countable pots.

no but having 500 routes distributed in many files and only show the call to those files its called "hide the trash under the carpet" explaining: you did not optimize anything, you just put it somewhere hidden. but your 500 routes still there

and i know this because we have done the same thing before and with rails too.

Very nice. Going to have to give Picplum a similar treatment.

@azendal What's wrong with 500 routes? How do you know it's not optimized already?

This reminds me strongly of what I did to tame db/seeds.rb (using db/seeds/*.rb) on most of my projects. This makes a lot of sense.

@azendal more than one type of 'optimizing'. this would make managing the routes far easier for dev's with no difference to rails. i'd rather deal with a 50 line routes file specific to a section of the app, than mess around in 500+ lines from all over

I don't get the point of people who are complaining about instance_eval, because ActionPack uses the same technique to draw routes: https://github.com/rails/rails/blob/45d6cd94b3ef2ec77166def41f29188445b35608/actionpack/lib/action_dispatch/routing/route_set.rb#L260

@jodosha Who's complaining about instance_eval? I was just asking because I didn't know the use of it. Occam's razor works most of the time.

Nice code. Yet another way to define routes. Ok.

"@mrcasais, because then the config/routes/x.rb files do not need any wrapping, they can just use the route syntax directly."

Now what problem are we really solving again? It's not like having the do block in each x.rb routes file was such a burden. Maybe I'm missing more context of this gist?

austinthecoder nothing, and its irrelevant to the point of putting them into other files

fullybaked, that is right ;). its just organizational change, nothing else

why something like "draw" method doesn't get into core?

how about defining the routes in the controllers, that could be done in a similar manner.

@joaomilho See DHH's comment above. The draw method should be in master soon.

@nicholaswyoung /me facepalm

@brainopia probably in anticipation of moving it to core. I don't know relative paths would work from a gem to your project where the file would actually be held. Or if he actually had this abstracted into a lib rather than sitting in the top of his rails.config. Prolly just makes it obvious where the path is going to be referenced so that the code can sit anywhere.

Very nice indeed. I slightly updated it to keep namespaced routes in subfolders: https://gist.github.com/2507892. Works great for me.

  draw :projects # => config/routes/projects.rb

  namespace :admin do
    draw :projects # => config/routes/admin/projects.rb
  end

@azendal since you seem to be missing the implicit point: organizational changes for files has known value. It's an 'ergonomic' improvement that aides the mind in the workflow. Your chiding misrepresents that value.

yes i already commented that its an organizational improvement, and that from that point is really good.

"@azendal Highly recommend you read Martin Fowler's "Clean Code". Perhaps when you understand the concept of seperating things that change from things that don't, you'll understand this small optimisation has value."
Gavin Laking

"This trips my rant bit. "Value" compared to what? The 800 outstanding
Issues in github/rails? Who says he doesn't understand that? And I'd wish
people would stop worshiping other people books like they're the solution
to cancer and a something to beat other peoples opinions with."
Christopher H. Laco

Thx Christopher.

Gavin
... did you really read the book? lets assume you did.

naming methods should reveal intention right?

def draw(routes_name)
instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb")))
end
since when draw is an alias for loading and evaluating a file?
Chapter 2 on the book you recommend Meaningful Names i still assume you read the book.

class ActionDispatch::Routing::Mapper
def draw(routes_name)
ok so we patched the class here nice API right?

BCX::Application.routes.draw do
draw :api
draw :account
draw :session
draw :people_and_groups
draw :projects
draw :calendars
draw :legacy_slugs
draw :ensembles_and_buckets
draw :globals

this is called sequence, but as you see we use the same draw method called inside a draw method and we do this many times
instead of passing an array.

or even better:

Remember that thing convention over configuration?

how about

Application.routes.load :all

now this is something that reveals a good intention.

instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb")))

instance_eval reveals that the code inside assumes that its on the class forcing the developer to know in advance
about this constrain, that once into the rails core you will have to read the documentation.

Other possible problems. if you want to avoid listing manually all the files that need to be included, how do you do this
in the right order? something i don't have an answer for right now without putting more stuff on the API.

with all this, i hope you think i know what i am talking about?

Looks great.
I agree with @kulesa that there should be some nesting functionality.
Probably by namespace, or else by successive draw. I mean if in routes.rb there is draw :admin and in routes/admin.rb there is draw :usersites, it could look up routes/api/usersites.rb instead of routes/usersites.rb.
Thanks

Another slight update to @kulesa's solution for namespace support. This adds support for scope, in addition to namespace routes ( see https://gist.github.com/2507892 ):

class ActionDispatch::Routing::Mapper
  def draw(routes_name)
    instance_eval(File.read(Rails.root.join("config/routes#{@scope[:path]}", "#{routes_name}.rb")))
  end
end

seems like routes get cached in development env, any advice on how to avoid it?

@freegenie +1
any workaround to that?

To get paths reloaded in dev mode, I ended up using in application.rb:

config.paths['config/routes'].unshift *Dir[Rails.root.join('config/routes/*.rb')]

Not the best line of code ever but does the job..

@apneadiving Thanks! Additionally I had to wrap the code in config/routes/*.rb files by a "ApplicationName::Application.routes.draw do" block otherwise I get undefined method `resources'.

@apeadiving @applicat I think it might be better form to throw that line into config/environments/development.rb rather than application.rb, since it is unclear to me how this would affect the loading order of the routes. This way, at the very least, in production the @dhh 's 'draw' method would allow your routes to be defined in the order that you declare each draw method.

@logical42 You could make a diff of "rake routes" results on your terminal before and after to see the affect on loading order.

But after some Rails updates my application is now on Rails 3.2.13 and don't need these hacks anymore (path unshifting and "ApplicationName::Application.routes.draw do" block).

Reload just seem to work through Rails now.

This is an awesome feature. Is it in master yet? I'm unable to find it in the code nor is it documented.

this fails for RAILS 4:

config.paths['config/routes'].unshift Dir[Rails.root.join('config/routes/.rb')]

Any thoughts?

@rubytastic you can always force Rails to reload routes from your middleware!

class RoutesReloader
  def initialize(app)
    @app = app
  end

  def call(env)
    Rails.application.reload_routes!

    @app.call(env)
  end
end

# in config/environments/development.rb

config.middleware.use RoutesReloader

Enjoy reloading routes on every request!

@shime it works, but makes application very slow:

time = Benchmark.measure { 10.times { Rails.application.reload_routes!  }  }

=> #<Benchmark::Tms:0x007fb4809b3840
 @cstime=0.0,
 @cutime=0.0,
 @label="",
 @real=4.654909,
 @stime=0.020000000000000018,
 @total=4.640000000000004,
 @utime=4.6200000000000045>

It adds more than 450 ms for every request.

Hopefully there is still other possible solution: we can use ActiveSupport::FileUpdateChecker for tracking changes in config/routes directory:

class RoutesReloader
  ROUTES_PATH = Dir.glob("config/routes/*.rb")

  def initialize(app)
    @app = app

    @routes_reloader = ActiveSupport::FileUpdateChecker.new(ROUTES_PATH) do
      Rails.application.reload_routes!
    end
  end

  def call(env)
    @routes_reloader.execute_if_updated

    @app.call(env)
  end
end

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.