Proposal: path based Phoenix modules naming

suggestion
#1

Currently Phoenix uses “weird” naming convention that controllers (and other modules) are stored in paths like lib/app_web/controllers/foo_controller.ex and are named AppWeb.FooController which for me is:

  1. Unnatural as I would expect it to be named after path, which is common practice in almost all other Elixir libraries.
  2. Duplicates controller part in path.

Instead what I am proposing is to change that to:

  • lib/app_web/controllers/foo.ex as path
  • AppWeb.Controllers.Foo as module name

This also results in IMHO cleaner routing, as (when using scopes) we can do:

scope "/", AppWeb.Controllers do
  resource "/foos", Foo
end

Which skips IMHO redundant Controller part of the name.

1 Like
#2

Afaik the reason why phoenix opted out was that by common convention multiple modules do alias to the same name. AppWeb.Controllers.Foo and AppWeb.Views.Foo would both be aliased to Foo. This is at the detriment of searchability and glanceability. Also I don’t really feel like “Controllers” and “Views” is a really worthwhile namespaces, while a module being some Controller is actually what differenciates it from it’s View counterpart (if existing). It might seem repetitive, but I feel it’s more useful that way.

2 Likes
#3

Simple question, when is last time you have aliased controller? To be honest for me the answer is: newer. It could make slight difference in pre-context universe where we had model named Foo used directly in controller FooController. But as that is discouraged it is IMHO better to change that convention now, as this will IMHO provide better experience and accidentally force better naming/context utilisation. I have used it in couple of my projects, Imager is the one with source code publicly available.

Also as there is :as option available in alias then I do not find this much of a problem.

#4

It is not about aliasing the controller, it is that you usually alias the context and schemas inside controllers and views and now thinking about what Foo means will become much harder.

We have had this discussion a couple times. Another point often repeated is that people shouldn’t expect Phoenix to change its naming structure any time soon, as doing so one more time, when the resources just finished catching up to the new structure, can be very detrimental to its adoption.

4 Likes
#5

Another reason, is that using the quick open for files in a lot of editors is much harder when the files are named the same thing. So, if you have a foo.ex schema and a foo.ex controller, it’s much harder to tell them apart.

3 Likes