What does your ideal version of Phoenix look like?

Phoenix Forum Chat / Discussions
,
1

One thing I love about our community is the high standard set by the Elixir, Phoenix, Nerves and Erlang core teams… another thing I like is how others wish to raise those standards even higher :lol:

So I thought it would be a nice idea to post a series of threads for just that :003:

Please let us know what your ideal version of Phoenix looks like in this thread :smiley:

Other threads in this series

2

13 posts were split to a new topic: What does your ideal version of Phoenix look like - fork - template engine

4

Less macros, more functions instead. Most irritating examples:

  • my_app_web.ex which use __using__/1 magic for including different set of modules in different parts of the application, especially when most of them do not need such at all, and should be left up to the user whether they want to include some of the headers
  • Phoenix.Channel.intercept/1, is there any good reason why this is macro rather than just module attribute?
  • Phoenix.ConnTest.{method} macros, what is the advantage over plain functions?

Also I would change naming from MyAppWeb.ActionController to MyAppWeb.Controllers.Action (the same for views, channels, sockets, etc.) so it will suit general naming convention within Elixir.

7 Likes
9

I love the explicit parts of Phoenix, like endpoint.ex listing out all the plugs that run before the router.

I remove web.ex from Phoenix projects, as it hides the source of the functions that are imported.

My ideal Phoenix wouldn’t support convention based selection of the view module from the controller module name for the sake of saving a single function parameter.

It’s great that Phoenix lets me use it in a way that is explicit and free of magic :slightly_smiling_face:

8 Likes
13

One of my rules is alias > import, and if you must import, import :only, and never from macros.

3 Likes
15

I would prefer MyAppWeb.Action.Controller, MyWebApp.Action.View etc so modules are grouped by the business domain rather than the “kind” of module.

4 Likes
16

The problem I see is that controllers and views will not be grouped together anyway, as it is quite often that controller Foo returns type with completely different view. And often view will also use other views, so this will be problematic there as well.

In general I prefer to view each of these parts as independent from each other, as this is the idea behind MVC, that each of this layers do not depend on each other and can be used independently from other.

2 Likes
20

There’s no reason why ever directory need to have each of the N different kinds of things in it. Unlike with grouping by kind there is no forced coupling.

21

Just a quick note to say I will try to split any large-ish forks into their own threads - helps to keep all of the discussions focused and easy to follow :003:

First fork here: What does your ideal version of Phoenix look like - fork - template engine

1 Like
22

alias > import, and if you must import, import :only, and never from macros

100% this.
There’s something similar in the Library guidelines:

While there are many situations where using a module is required, use should be skipped when all it does is to import or alias a module. In a nutshell, alias is simpler and clearer than import , and import is simpler and clearer than use .

But it would be more effective if our phoenix generators encouraged that style for application code too :slight_smile:

4 Likes
23

Better form creation like formex.

input type month support in phoenix.html library. That’s the only form input that isn’t supported iirc.

Context/schema can really be a trap sometime not sure if there is a fix. You need plan before hand on what context to have. I ended up with one context with lots of code because I’m a baddie and not entirely sure if refactoring is worth it.

Not sure if there is a clear way to share code across context and code across view. I know you can share stuff across controller via plugs.

I want haml or slime but chris’s tweet about complexity is making me rethink about wanting an alternative to html. It would be nice since I use vim and tmux on a tiny 15’’ laptop.

A clear go to library for authorization and roles maybe have it built in to the framework but I’m not sure if it’s worth it. There’s coherence and guardian and I’ve been using coherence. IIRC guardian is more for authentication.

Laravel have this neat homestead vagrant box. I kinda wish we got a go to vagrant box deal or a go to container image for docker.

Not sure if this should be in here but Ecto’s default naivedate support for backward compatibility. I wish installing it to phoenix would make Ecto use the non-naivedata version. I didn’t know the default of naivedate until I just wrote some code with Ecto on insert_all.

I know it sounds all complaints but I enjoy using phoenix so far and my side project is coming along great. So please don’t see this as all doom and gloom it’s a great framework and the people who have put work into it are doing an awesome job.