4 ms·

Yep. I wish `pipeline`, `scope` and `resources` in Phoenix router and also all the `use MyApp.Web, :x`, would just die in a fire. Thank goodness they got rid

Yep. I wish `pipeline`, `scope` and `resources` in Phoenix router and also all the `use MyApp.Web, :x`, would just die in a fire. Thank goodness they got rid of views though I still am annoyed that the default path resolution on templated content isn't explicit. The crazy thing is that the most amazing part of phoenix, liveview, is almost no macros.

sodapopcan 3y ago
I never use `resources` though have no beef with `pipeline` or `scope`, though I haven't thought too much about it. It is a little weird getting used to which modules are getting auto-qualified and which aren't, but I'm long passed that. And that is actually what is "fixing" the cyclical dependency issue. What's wrong with the `use MyApp.Web, :x`? You can easily get rid of it as it's just generated boilerplate. It's a nice little pattern to allow all the different things to share the view helpers. If you'd like to be extra explicit, though, just delete the file and include everything manually. I'm indifferent on views because I never really used them, haha.
- halostatue 3y ago
  I personally would prefer something like: defmodule MyApp.Web.Router do use MyApp.Router end over defmodule MyApp.Web.Router do use MyApp, :router end but that’s a preference.
  - sodapopcan 3y ago
    You can do that if you want. Just remove `def router` from `MyAppWeb` move its contents over to a custom module: defmodule MyAppWeb.Router do defmacro __using__(_) do quote do use Phoenix.Router, helpers: false import Plug.Conn import Phoenix.Controller import Phoenix.LiveView.Router end end end But why the dislike for passing a second argument to `use`? It keeps everything together pretty nicely.
    - halostatue 3y ago
      Mostly because we’re using an umbrella at the place of work, and we absolutely don’t want those boundaries crossed.
      - sodapopcan 3y ago
        Oh! Well I don't know your setup but you could always add a top level `PhoenixHelpers` namespace (or a better name) that holds these generic types of things that can be shared between apps. Though again I really don't know your set up. Like maybe you have an app whose router doesn't need `Phoenix.Controller` so then this wouldn't make sense.
arrowsmith 3y ago
> I wish `pipeline`, `scope` and `resources` in Phoenix router and also all the `use MyApp.Web, :x`, would just die in a fire. How would you prefer it worked/looked? > I still am annoyed that the default path resolution on templated content isn't explicit. What do you mean by this? In the new 1.7 approach to views, you explicitly set the path in each view using `embed_templates` (if you're not defining your HEex directly within the view module itself.) What part isn't explicit?
- throwawaymaths 3y ago
  > What do you mean by this? In the new 1.7 approach to views, you explicitly set the path For example, if you wrote a liveview called FooView in /path/to/my_liveview, a default render() will look for /path/to/my_liveview/foo_view.html.heex (Also note auto-snakecasing) Btw, this is still a different semantic if you do the deadview equivalent, which will try to do a path resolution in /templates. I guess these are minor complaints but I would much prefer they use the same default strategy and, say, pass the path in `use Phoenix.Liveview`
  - arrowsmith 3y ago
    > This is still a different semantic if you do the deadview equivalent, which will try to do a path resolution in /templates. Not true in 1.7 - views* don't have any kind of "default" template resolution; you have to explicitly state the template path with `embed_templates`. That is if you're not just defining your HEEx directly within the view module itself, as I already mentioned. *By "views" I mean the new style that uses `use MyAppWeb, :html`, not the old style you describe which is now (in 1.7+) only available as the external dependency `phoenix_view`. The new style of module is still called a "view" by the docs: https://hexdocs.pm/phoenix/request_lifecycle.html#from-endpoint-to-views https://hexdocs.pm/phoenix/request_lifecycle.html#from-endpo...

sodapopcan 3y ago

I never use `resources` though have no beef with `pipeline` or `scope`, though I haven't thought too much about it. It is a little weird getting used to which modules are getting auto-qualified and which aren't, but I'm long passed that. And that is actually what is "fixing" the cyclical dependency issue. What's wrong with the `use MyApp.Web, :x`? You can easily get rid of it as it's just generated boilerplate. It's a nice little pattern to allow all the different things to share the view helpers. If you'd like to be extra explicit, though, just delete the file and include everything manually. I'm indifferent on views because I never really used them, haha.

halostatue 3y ago
I personally would prefer something like: defmodule MyApp.Web.Router do use MyApp.Router end over defmodule MyApp.Web.Router do use MyApp, :router end but that’s a preference.
- sodapopcan 3y ago
  You can do that if you want. Just remove `def router` from `MyAppWeb` move its contents over to a custom module: defmodule MyAppWeb.Router do defmacro __using__(_) do quote do use Phoenix.Router, helpers: false import Plug.Conn import Phoenix.Controller import Phoenix.LiveView.Router end end end But why the dislike for passing a second argument to `use`? It keeps everything together pretty nicely.
  - halostatue 3y ago
    Mostly because we’re using an umbrella at the place of work, and we absolutely don’t want those boundaries crossed.
    - sodapopcan 3y ago
      Oh! Well I don't know your setup but you could always add a top level `PhoenixHelpers` namespace (or a better name) that holds these generic types of things that can be shared between apps. Though again I really don't know your set up. Like maybe you have an app whose router doesn't need `Phoenix.Controller` so then this wouldn't make sense.

arrowsmith 3y ago

> I wish `pipeline`, `scope` and `resources` in Phoenix router and also all the `use MyApp.Web, :x`, would just die in a fire. How would you prefer it worked/looked? > I still am annoyed that the default path resolution on templated content isn't explicit. What do you mean by this? In the new 1.7 approach to views, you explicitly set the path in each view using `embed_templates` (if you're not defining your HEex directly within the view module itself.) What part isn't explicit?

throwawaymaths 3y ago
> What do you mean by this? In the new 1.7 approach to views, you explicitly set the path For example, if you wrote a liveview called FooView in /path/to/my_liveview, a default render() will look for /path/to/my_liveview/foo_view.html.heex (Also note auto-snakecasing) Btw, this is still a different semantic if you do the deadview equivalent, which will try to do a path resolution in /templates. I guess these are minor complaints but I would much prefer they use the same default strategy and, say, pass the path in `use Phoenix.Liveview`
- arrowsmith 3y ago
  > This is still a different semantic if you do the deadview equivalent, which will try to do a path resolution in /templates. Not true in 1.7 - views* don't have any kind of "default" template resolution; you have to explicitly state the template path with `embed_templates`. That is if you're not just defining your HEEx directly within the view module itself, as I already mentioned. *By "views" I mean the new style that uses `use MyAppWeb, :html`, not the old style you describe which is now (in 1.7+) only available as the external dependency `phoenix_view`. The new style of module is still called a "view" by the docs: https://hexdocs.pm/phoenix/request_lifecycle.html#from-endpoint-to-views https://hexdocs.pm/phoenix/request_lifecycle.html#from-endpo...