Argument/variable naming: Phoenix.Socket vs Phoenix.LiveView.Socket

Names are always contextual. In the context of a live view module the %Phoenix.Socket{} is never accessible, so you don’t need to distinguish the live socket you have from an ordinary phoenix socket. In a similar way, we always refer to a %Plug.Conn{} as conn even though there is also a cowboy connection out there making the request work. The cowboy connection isn’t really accessible in the context of a plug, so conn has plenty of context and there’s no ambiguity.

To interpret contextual names it’s necessary to be aware of the particular context which is not always easy when there’s many contexts and you’re not actually working on the module you’re looking at.
When names are self explanatory there’s no need to figure anything out.
Explicitness really is the only thing Python has over Elixir in my opinion.

I’m going to agree with @benwilson512 here. The point of not exposing lv_socket vs phx_socket is that it doesn’t really matter in the LiveView itself. As a public consumer of LiveView, you shouldn’t need to worry about what the Socket is. If Phoenix wanted to swap out the implementation of Socket completely, they could do so and it wouldn’t affect you.

Phoenix itself does distinguish between the types of sockets. You can find an example in the LiveView source code. I think this is interesting because it shows that explicitness is being prioritized where important, and removed where it’s not important. If you are curious about how the sausage is made, then the source code is very accessible. This is a very pragmatic approach, imo.

It would be helpful to have more examples here. I’ve generally felt like Elixir as a language is really explicit. Libraries like Phoenix are good stewards of quality code, as well.

What concrete problem are you running in to?

To me live_socket would expose that I’m looking at a live view.

Another example could be:

which is about assigns vs conn (.assigns)

The concrete problem is that I sometimes loose track of what is what.
For example today I was doing something like:

Phoenix.LiveView.live_render @conn,
  MyLiveView,
  looks_like_assigns: "but should be one of [:session, :container, :id, :router]"

And then I don’t get any feedback saying looks_like_assigns will never work,
probably you mean something else.
(of course I should read the docs better)

Can you elaborate on how that connects to socket variable name conventions?

To address what feels like a different topic, live_render having different args than render, I think a PR validating the options to live_render would be a great addition. It’s still very much a work in progress.

Well that example doesn’t.
I was trying to give an example of explicitness that would help.
With regard to socket variable name conventions many times I will pass sockets to helper modules that aren’t using Phoenix.LiveView.
Then, when I want to assign things, I would call Phoenix.LiveView.assign directly.
Which doesn’t work when it’s not a live socket.

Right, if I have a module that has helpers and some are for live view and some are not, then in THOSE functions I would have the variable be named live_socket. The context of the helpers is different from the context of a live view module. The caller of a function and the function argument don’t need to be exactly the same name. Type specs can be very helpful there too.