To whomever it may concern, here’s a link to how I solved the problem of having more than just one template file per live component.
That is great 
Does it work the same way for live view? Want to publish it as a small library on hex.pm?
Good question. Actually, never thought of using it in a live view for there’s a common pattern to rely on the Phoenix.View.render/2 function and I created this module because there there was no such functionality available for the LiveComponents.
But now that you mention it, I can try and see. If you have the time to try it first (with a live view), you’re more than welcome.
And if it does work there too or it requires minor modifications, yes, I could publish it as a small library.
Cool. Will try it later today or tomorrow.
Worked in live view like a charm!
1 Like
That’s great. Now the only thing remaining prior to releasing it as a library is to figure out a proper name for the module, given its generic application for both the live components and live views and the fact that it extends the standard functionalities of LiveView.
Is there any prescribed LiveView extension naming convention? E.g. Phoenix.LiveView.Renderer.Helpers, or to avoid confusing the library name with the official LiveView releases, something like: Extensions.LiveView.Renderer ?
What do the LiveView authors have to say @josevalim? Any suggestions given the fact that a good part of the code in this small library to be was taken from the Phoenix.LiveView.Renderer module?
Any name is fine as long as you don’t step into Phoenix or LiveView namespaces, as to avoid conflicts in the future. For example, do: PhoenixLiveViewWhatever, don’t do Phoenix.LiveViewWhatever or Phoenix.LiveView.Whatever.
4 Likes
So, Extensions.LiveView.Renderer is ok, right?
If your package is called extensions, yes. 
If you want something more concrete: one suggestion is PhoenixLiveViewMultiRender
1 Like
Thanks, Jose. I like the MultiRender name, but will stick to the idea of the Extensions top-package as there may be more of those on my behalf over time and I dislike too long camelized names for they remind me of Java which was cool back in 1998, but Elixir and everything about it is so much paradigmatically superior that I have no desire to get reminded of the former.
Therefore: Extensions.LiveView.MultiRender
Just want to highlight that installing your library would look something like this:
{:extensions, "~> 1.0.0"}
A bit confusing if you’d ask me. I’m more for clear names, where it’s obvious what the library is for. Also it will be easier to find it on hex.pm.
{:phoenix_live_view_multi_renderer, "~> 1.0.0"}
{:live_view_multi_renderer, "~> 1.0.0"}
{:lv_multi_renderer, "~> 1.0.0"}
{:multi_renderer, "~> 1.0.0"}
2 Likes
Not necessarily. It may also look like:
{ :extensions_live_view_multi_render “~> 1.0.0”}
or indeed
{ :extensions_lv_multi_render “~> 1.0.0”}
Right?
I was under the impression that the package name is also how your root module is called. Maybe not enforced, but it’s the typical case.
So the package name :extensions_lv_multi_render means that the root module is ExtensionsLvMultiRender and that’s cool. But to have the main module called Extensions is different.
Why would I need a package root name module?
What is wrong with just having one module in the library named Extensions.LiveView.MultiRender while expecting to add more Extensions.mn.xy in the future without ever having the root module Extensions.ex?
I am asking sincerely.
I mean a root namespace, didn’t mean that there needs to be a real file for it.
My point still stands though, that I expect the package from hex to have the root name space exactly like the package is called. So if the top namespace for the module Extensions.LiveView.MultiRender is Extensions, I would expect the hex package to be called :extensions which I find too generic and confusing.
In the end - it’s your choice. You made the library and it’s awesome! I will use it even if it’s called :extensions 
But please sleep on the naming again if you can
I like your last comment. But I still don’t get your point and am beginning to doubt my own understanding of the naming conventions in Elixir.
Why do you think I can’t make the library to look like this:
full module name:
Extensions.LiveView.MultiRender
directory tree:
- extensions_live_view_multi_render
- lib
- multi_render.ex
deps:
{ :extensions_live_view_multi_render "~> 1.0.0.}
I think nothing prevents you technically. But this is not the naming I’d expect from a library. All libraries I’ve seen have the same package name and the root module name.
Ok. But those libraries are not extensions of a very particular functionality at a very particular hierarchical level of another library, right?
What I am trying to say is that by the time I make the very next extension (which btw, unless the authors of LiveView come up with the helpers for lists in containers fast, is going to be soon), this next extension library will look like
extensions_live_view_distiller
So it will make sense to have them in your dependency folder listed like this:
…
decimal
ecto
ecto_sql
extensions_live_view_distiller
extensions_live_view_multi_render
file_system
floki
…
After a serious consideration (the proverbial sleeping over it) and reading the instructions on naming on hex.pm, I decided to follow the way that is somewhere in between what Jose suggests and what I feel like is right thing to do.
The module name will be: PhoenixLiveViewExt.MultiRender
and the library name will: lv_multi_render
That way I respect the convention and ownership of the Phoenix.LiveView, the library name stays short, it is clear that it’s about LiveView to whomever uses it and I don’t end up with a long module base name which I really want to avoid.
Didn’t think this would be such a mind job.
Awesome! Just curious what’s keeping you from naming the package phoenix_live_view_ext? Because you want to publish your other ideas as separate libraries?
Hex.pm says:
- If you are providing functionality on top of an existing package, consider using that package name as a prefix. For example, if you want to add authentication to Plug, consider calling your package
plug_auth(orplug_somename) instead ofauth(orsomename).
You could then just add more modules to the library and users will take only parts that they need.
Regardless, I’m looking forward to the first version!
1 Like
