-
-
Notifications
You must be signed in to change notification settings - Fork 127
Description
There are a couple of potential gotchas with our current internal handling of the Roda root (aka r.root).
1. Because the root handler in bridgetown_server.rb is initialized before the loop of all our Bridgetown::Rack::Route subclasses, none of those subclasses get to run before the root is handled. That's fine for static root (aka index.erb in src), but for a dynamic route (using the file-based routes plugin or otherwise) that means route logic that might need to run like auth, special logging, etc. will be bypassed. So we would need to move our call to scope.initialize_bridgetown_root down below the loop, but that's a breaking change (already a test breaks in bridgetown-routes because it's not expecting a static index to trounce a dynamic index when present).
2. Even if that problem gets resolved, a fully dynamic app using a "controllers" paradigm would want to establish its own r.root handling. For example, in a demo project I'm working on:
class Routes::HomeRoutes < Bridgetown::Rack::Routes
route do |r|
# route: GET /activity
r.get "activity" do
Home::HomeControllers::ActivityController.new
end
# route: GET /activity/:type
r.get "activity", String do |activity_type|
Home::HomeControllers::ActivityController.new activity_type:
end
# route: GET /
r.root do
Home::HomeControllers::IndexController.new
end
end
endThis is only possible if I monkey-patch the bridgetown_server.rb to check for a configuration option, like so:
scope.initialize_bridgetown_root unless Bridgetown::Current.preloaded_configuration.custom_roda_rootI'm not sure if there's another more elegant solution.
At any rate, I'm filing this as a "bug" but it's more of a thorny question at present.