Namespaced action generates incorrect `to` option

[radar]

Running:

hanami g api/users.thing

Gives me a route:

get "/api/users/thing", to: "api/users.thing"

When loading the Hanami app through hanami s (http://localhost:2300), I see this error:

Puma caught this error: Could not find action with key "actions.api/users.thing" in Chirper::App

To fix this, define the action class Chirper::Actions::API::Users::Thing in /Users/ryan.bigg/code/chirper/actions/api/users/thing.rb
 (Hanami::Routes::MissingActionError)

However, in hanami console:

Chirper::App.key?("actions.api/users.thing") #=> true

The same is true if I replace the dots with slashes in that.

So why is it then that the router cannot find this action? Should the route that is generated be api.users.thing instead of api/users.thing?

[timriley]

Hey @radar! Thanks for reporting this. I think you've come across one of the (many) edge cases that the CLI could do better at normalising.

Right now, I believe the action generator is expecting to receive something that's exclusively dot-delimited.

If you could re-run the command (or run a similar command) passing api.users.thing, does everything work like you would expect?

[timriley]

And the reason that the component resolution from the container works with a "/" as a key namespace delimiter is purely coincidental — because it happens to match the unix file path separator. And it only works when lazy loading (i.e. for a prepared instead of booted app), because it uses the component name to find a matching file from the filesystem; in this case the slashes are treated as literal filesystem path values, and it's only by luck that they happen to match up.

If you type boot into the console and then try and call app.key?("actions.api/users.thing") after that, you'll get a false (as expected).

I'll need to have a think about whether we should add any special handling of slashes here here.

[jodosha]

@timriley What do you think to normalize that path in router and container? By normalize I mean to always use the dot separator.

I assume that in other parts of the framework we always expect a dot separator. This expectation may lead to bugs when dealing with container keys.

[timriley]

@jodosha Yep, I think using/normalizing to dots in as many places as it is sensible would be a good way to go here.