Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
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
@rtdp

This comment has been minimized.

Show comment Hide comment
@rtdp

rtdp Apr 25, 2012

awesome..

rtdp commented Apr 25, 2012

awesome..

@aroc

This comment has been minimized.

Show comment Hide comment
@aroc

aroc Apr 25, 2012

Hot.

aroc commented Apr 25, 2012

Hot.

@anildigital

This comment has been minimized.

Show comment Hide comment
@anildigital

anildigital Apr 25, 2012

awesome it is.

awesome it is.

@mrcasals

This comment has been minimized.

Show comment Hide comment
@mrcasals

mrcasals Apr 25, 2012

Why do you need to use instance_eval here?

Why do you need to use instance_eval here?

@dhh

This comment has been minimized.

Show comment Hide comment
@dhh

dhh Apr 25, 2012

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

Owner

dhh commented Apr 25, 2012

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

@mrcasals

This comment has been minimized.

Show comment Hide comment
@mrcasals

mrcasals Apr 25, 2012

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

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

@mtmcfarl

This comment has been minimized.

Show comment Hide comment
@mtmcfarl

mtmcfarl Apr 25, 2012

Nice organizational refactor.

Nice organizational refactor.

@daveott

This comment has been minimized.

Show comment Hide comment
@daveott

daveott Apr 25, 2012

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.

daveott commented Apr 25, 2012

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.

@dhh

This comment has been minimized.

Show comment Hide comment
@dhh

dhh Apr 25, 2012

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

Owner

dhh commented Apr 25, 2012

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

@brainopia

This comment has been minimized.

Show comment Hide comment
@brainopia

brainopia Apr 25, 2012

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?

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?

@jherdman

This comment has been minimized.

Show comment Hide comment
@jherdman

jherdman Apr 25, 2012

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

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

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 25, 2012

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

azendal commented Apr 25, 2012

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

@dhh

This comment has been minimized.

Show comment Hide comment
@dhh

dhh Apr 25, 2012

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

Owner

dhh commented Apr 25, 2012

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

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 26, 2012

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

azendal commented Apr 26, 2012

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

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 26, 2012

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

azendal commented Apr 26, 2012

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

@dodeja

This comment has been minimized.

Show comment Hide comment
@dodeja

dodeja Apr 26, 2012

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

dodeja commented Apr 26, 2012

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

@austinthecoder

This comment has been minimized.

Show comment Hide comment
@austinthecoder

austinthecoder Apr 26, 2012

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

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

@jnx

This comment has been minimized.

Show comment Hide comment
@jnx

jnx Apr 26, 2012

Very sexy...

jnx commented Apr 26, 2012

Very sexy...

@tdd

This comment has been minimized.

Show comment Hide comment
@tdd

tdd Apr 26, 2012

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.

tdd commented Apr 26, 2012

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.

@fullybaked

This comment has been minimized.

Show comment Hide comment
@fullybaked

fullybaked Apr 26, 2012

@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

@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

@jodosha

This comment has been minimized.

Show comment Hide comment
@jodosha

jodosha Apr 26, 2012

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 commented Apr 26, 2012

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

@mrcasals

This comment has been minimized.

Show comment Hide comment
@mrcasals

mrcasals Apr 26, 2012

@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.

@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.

@claco

This comment has been minimized.

Show comment Hide comment
@claco

claco Apr 26, 2012

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?

claco commented Apr 26, 2012

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?

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 26, 2012

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

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

azendal commented Apr 26, 2012

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

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

@joaomilho

This comment has been minimized.

Show comment Hide comment
@joaomilho

joaomilho Apr 26, 2012

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

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

@jlebrech

This comment has been minimized.

Show comment Hide comment
@jlebrech

jlebrech Apr 26, 2012

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

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

@nicholaswyoung

This comment has been minimized.

Show comment Hide comment
@nicholaswyoung

nicholaswyoung Apr 26, 2012

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

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

@joaomilho

This comment has been minimized.

Show comment Hide comment
@joaomilho

joaomilho Apr 26, 2012

@nicholaswyoung /me facepalm

@nicholaswyoung /me facepalm

@j-mcnally

This comment has been minimized.

Show comment Hide comment
@j-mcnally

j-mcnally Apr 26, 2012

@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.

@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.

@albandiguer

This comment has been minimized.

Show comment Hide comment
@albandiguer

albandiguer Apr 27, 2012

sexy as, thanks.

sexy as, thanks.

@kulesa

This comment has been minimized.

Show comment Hide comment
@kulesa

kulesa Apr 27, 2012

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

kulesa commented Apr 27, 2012

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
@NewAlexandria

This comment has been minimized.

Show comment Hide comment
@NewAlexandria

NewAlexandria Apr 27, 2012

@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.

@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.

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 27, 2012

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

azendal commented Apr 27, 2012

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

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 28, 2012

"@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?

azendal commented Apr 28, 2012

"@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?

@azendal

This comment has been minimized.

Show comment Hide comment
@azendal

azendal Apr 28, 2012

@marcandre

This comment has been minimized.

Show comment Hide comment
@marcandre

marcandre May 2, 2012

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

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

@JurgenJocubeit

This comment has been minimized.

Show comment Hide comment
@JurgenJocubeit

JurgenJocubeit May 9, 2012

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

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
@freegenie

This comment has been minimized.

Show comment Hide comment
@freegenie

freegenie May 16, 2012

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

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

@shaynekang

This comment has been minimized.

Show comment Hide comment
@shaynekang

shaynekang Sep 21, 2012

@knoopx

This comment has been minimized.

Show comment Hide comment
@knoopx

knoopx Nov 8, 2012

@rtdp

This comment has been minimized.

Show comment Hide comment
@rtdp

rtdp Jan 27, 2013

@freegenie +1
any workaround to that?

rtdp commented Jan 27, 2013

@freegenie +1
any workaround to that?

@apneadiving

This comment has been minimized.

Show comment Hide comment
@apneadiving

apneadiving Jan 30, 2013

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..

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..

@volontarian

This comment has been minimized.

Show comment Hide comment
@volontarian

volontarian Feb 8, 2013

@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'.

@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'.

@logical42

This comment has been minimized.

Show comment Hide comment
@logical42

logical42 May 9, 2013

@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.

@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.

@volontarian

This comment has been minimized.

Show comment Hide comment
@volontarian

volontarian May 16, 2013

@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.

@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.

@evilmarty

This comment has been minimized.

Show comment Hide comment
@evilmarty

evilmarty Jul 2, 2013

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

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

@rubytastic

This comment has been minimized.

Show comment Hide comment
@rubytastic

rubytastic Sep 18, 2013

this fails for RAILS 4:

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

Any thoughts?

this fails for RAILS 4:

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

Any thoughts?

@shime

This comment has been minimized.

Show comment Hide comment
@shime

shime Sep 20, 2013

@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 commented Sep 20, 2013

@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!

@sharipov-ru

This comment has been minimized.

Show comment Hide comment
@sharipov-ru

sharipov-ru Mar 13, 2014

@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

@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
@joxxoxo

This comment has been minimized.

Show comment Hide comment
@joxxoxo

joxxoxo Sep 8, 2015

@sharipov-ru, it's much better but I'd like to add a small improvement:
ActiveSupport::FileUpdateChecker.new([], 'config/routes' => 'rb') do ... end
This way it should find new files as well.

joxxoxo commented Sep 8, 2015

@sharipov-ru, it's much better but I'd like to add a small improvement:
ActiveSupport::FileUpdateChecker.new([], 'config/routes' => 'rb') do ... end
This way it should find new files as well.

@iGEL

This comment has been minimized.

Show comment Hide comment
@iGEL

iGEL Nov 12, 2015

Guys, it's very outdated. You now can just require other routes files without monkey patching, they just have to repeat the Rails.application.routes.draw do:
config/routes.rb:

Rails.application.routes.draw do
  load Rails.root.join("config/routes/dev.rb")
  #...
end

config/routes/dev.rb:

Rails.application.routes.draw do
  scope "dev" do
    # ...
  end
end

No dynamic reloading tho, probably @sharipov-ru's reloader still works.

iGEL commented Nov 12, 2015

Guys, it's very outdated. You now can just require other routes files without monkey patching, they just have to repeat the Rails.application.routes.draw do:
config/routes.rb:

Rails.application.routes.draw do
  load Rails.root.join("config/routes/dev.rb")
  #...
end

config/routes/dev.rb:

Rails.application.routes.draw do
  scope "dev" do
    # ...
  end
end

No dynamic reloading tho, probably @sharipov-ru's reloader still works.

@lichtamberg

This comment has been minimized.

Show comment Hide comment
@lichtamberg

lichtamberg Dec 7, 2016

Anyone found a nice solution on how to seperate route files and still make them auto reloading during development?

Edit: Going now with a combination of the mentioned solutions...

# config/environments/development.rb
class RoutesReloader
  def initialize(app)
    @app = app

    @routes_reloader = ActiveSupport::FileUpdateChecker.new([], 'config/routes' => 'rb') do
      Rails.application.reload_routes!
    end
  end

  def call(env)
    @routes_reloader.execute_if_updated

    @app.call(env)
  end
end

Rails.application.routes.draw do
  ...
  config.middleware.use RoutesReloader
end
# config/routes.rb
Rails.application.routes.draw do
  routes = [:admin_routes, :admin_routes_old, :public_routes, :api_routes]
  routes.each{ |route_file| load Rails.root.join("config", "routes", "#{route_file}.rb") }
end

lichtamberg commented Dec 7, 2016

Anyone found a nice solution on how to seperate route files and still make them auto reloading during development?

Edit: Going now with a combination of the mentioned solutions...

# config/environments/development.rb
class RoutesReloader
  def initialize(app)
    @app = app

    @routes_reloader = ActiveSupport::FileUpdateChecker.new([], 'config/routes' => 'rb') do
      Rails.application.reload_routes!
    end
  end

  def call(env)
    @routes_reloader.execute_if_updated

    @app.call(env)
  end
end

Rails.application.routes.draw do
  ...
  config.middleware.use RoutesReloader
end
# config/routes.rb
Rails.application.routes.draw do
  routes = [:admin_routes, :admin_routes_old, :public_routes, :api_routes]
  routes.each{ |route_file| load Rails.root.join("config", "routes", "#{route_file}.rb") }
end
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment