Need help to understand how to split up routing tree in separate files

[milouse]

Hi,

I’m very sorry as the answer of this question surely involved more basic ruby knowledge than something specific to roda. However It’s only in the case of the development of a little web app with roda that I really struggle to understand how I can split my code to gain in readability.

I would like to avoid to have the whole world in a single ruby file. As my little web app involves a database, I’ve already been able to move all models related code in a model subfolder. My next step would be to split up the routing tree into several parts.

My first attempt was to embed the separated tree parts into different functions stored in different files. Before declaring my app, I required all that files, then I used a specific method to call that function when needed:

routes/feature1.rb

def route_for_feature1(routing)
  routing.get true { view '…' }
  routing.post 'save' { … }
end

routes/feature2.rb

def route_for_feature2(routing)
  routing.get 'hello' { view '…' }
  routing.post 'world' { … }
end

app.rb

Dir['routes/*.rb', base: __dir__].each do |route_file|
  require_relative route_file
end

class App < Roda
  route do |routing|
    handle_routes 'feature1', routing
    handle_routes 'feature2', routing
  end

  private  
  def handle_routes(route_name, routing)
    fun_name = "route_for_#{route_name}".to_sym
    routing.on(route_name) { send(fun_name, routing) }
  end
end

But I was afraid it was no very efficient, nor following any convention of roda. Thus I look for an already existing plugin and found the hash_route one, which seems to be the right things to use.

Thus I rewrite my code to look like the following:

routes/feature1.rb

hash_path '/feature1' do |routing|
  routing.get true { view '…' }
  routing.post 'save' { … }
end

routes/feature2.rb

hash_path '/feature2' do |routing|
  routing.get 'hello' { view '…' }
  routing.post 'world' { … }
end

app.rb

class App < Roda
  plugin :hash_routes

  Dir['routes/*.rb', base: __dir__].each do |route_file|
    require_relative route_file
  end

  route do |routing|
    routing.hash_paths
  end
end

However obviously I get a crash has the hash_path method is not defined in the various routes files. Thus I wonder how I should write this route files? Should I reopen my App class?

class App
  hash_path '/feature1' do
    …
   end
end

And in that case, it means I must require my route files after the declaration of my App?

Or is there another way to do it I just don’t know?

Thank you very much for your advices.

[kez]

Hi @milouse - I've based my own apps off of Jeremy's roda-sequel skeleton here (https://github.com/jeremyevans/roda-sequel-stack).

You can see the route splitting here (https://github.com/jeremyevans/roda-sequel-stack/blob/master/app.rb#L77-L87) and the route itself here (https://github.com/jeremyevans/roda-sequel-stack/blob/master/routes/prefix1.rb)

hash_branch can also do further nesting so you could have a route1_a.rb and route1_b.rb both serving /route1 and then splitting based on /a or /b - I don't have an advanced understanding of this plugin but hopefully referencing the links above will be helpful context.

[jeremyevans]

@kez I would definitely recommend the hash_routes approach. roda-sequel-stack is a good starting point if you want much of the setup taken care of for you. You can always just look at it and get ideas from it as opposed to cloning it if that suits your needs better.

Note that your example with hash_path won't work, since hash_path specifies a terminal path. You probably want to use hash_branch in each routing file, and r.hash_routes in your routing tree.

[milouse]

Oh, thank you both of you for your answer. It seems I was too tired yesterday evening, because I found this template project, but missed the route declaration 🤦 I’m glad to have found by myself that it was a matter of re-opening the app class.

I’m not sure I need to depend on rack-unreloader, and in any case, to be sure I correctly understand all of that: Unreloader is just a wrapper around require call? If yes, what is the difference between requiring the route file from the inside of the App class and requiring it from the outside? As the route file reopen the App class, I’d have put the various require call outside of the main App class. Thus is it purely cosmetic or is there any benefit of requiring them from inside? Thank you very much.

[jeremyevans]

Unreloader is responsible for setting up code reloading in development mode. If you don't need that, or plan on switching to another code reloading library, you could switch to plain require.

[milouse]

Thank you very much for your answer. Now I wonder what is the difference between requiring the route file from the inside of the App class or requiring it from the outside?

As the route file reopen the App class, I personnaly would have put the various require call outside of the main App class. Thus is it purely cosmetic or is there any benefit of requiring them from inside?

[jeremyevans]

Requiring them inside makes sure the app constant is already set before loading the route files, but otherwise there isn't much difference between the two.