Custom restructuring Phoenix Framework tradeoffs question

Have a look in this topic: Discussion about domain-orientated folder structures in Phoenix

Has this person considered code that must be reused between two or more features? Then their idea kind of falls apart.

Controller / view code isn’t really this way though. I definitely agree with you that "model" code definitely doesn’t belong to a specific controller. However for controller / view stuff there’s a decent argument for favoring a “pod” structure.

While not exactly the same, LiveView definitely takes more of a “page” oriented structure since with a given live view + leex / heex template you generally have a bunch of functionality all right next to each other.

I don’t disagree but let’s take this to the extreme: should each feature have a copy of the root layout code then?

The stance described in OP seems too extremist and narrow-minded to me. Partially applied it is valuable but I’ve rarely seen people advocate for such things in an moderate manner. It’s usually an all-or-nothing affair. Maybe it was a bad luck on my part, I don’t know.

Thank you!

The way being proposed is indeed all the model, view, controller as described FWIW

In practice, it’s never about the extremes though. As there is a ‘data’ App and a separate ‘web’ AppWeb both styles can be used together.

If we look at how the phx generator creates the data app, we see vertical slicing as far as I can remember. Except for migrations which are all in one folder*. It’s the web app that (historically) uses horizontal slicing and although it can be beneficial, I rather use vertical slicing there too.

LiveView seems to move towards vertical slicing, with the template files next to the rest of the code for a page/view.

*Django puts migrations within the ‘feature’. Con: touch two features at once and you have two separated migration files.

I would not favor an all-in-one approach with models next to views, as having both an data app and web app makes a good boundary. So there I draw a line: The data app is meant for handling data requests, the web app for handling web requests. Easy distinction .

It also allows me to have a clear seperation between types of ‘frontend’. For example:

data/
web_api/ (using jwt tokens)
web_live/ (using sessions)

Sasa Juric (iphone won’t let me spell it correctly) has a good blog serie about the way the company he works for separates code(files). Highly recommend to read them.

Although being designed for React, you can find value information about vertical slicing in there.

I use that approach in my app and I’m pretty happy with it! I don’t use generators though. I even have two separate “myapp_web.ex” files - one for the SSR app and one for the API:

- lib
  - foo
    - ...
  - foo_web
    - app
      - session
        - new.html.heex
        - session_controller.ex (use FooWeb.App, :controller)
        - session_view.ex
      - ...
    - mobile_api
      - message
        - message_controller.ex (use FooWeb.MobileApi, :controller)
        - message_view.ex
      - ...
    - app.ex
    - mobile_api.ex