4 ms·

> 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/l

> 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...

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...