Breaking up LiveView templates into partials for DRY code?

Hello,

I am really really new to Elixir, and although I have tried to get started with it earlier - I, finally, started rewriting a monolith Rails app using Phoenix to fix a few things we were having troubles with (and o’course, learning new stuff helps).

So far, I am loving the components we have ported to our Elixir application, and Phoenix LiveView has been incredibly useful to speed things up. We were using Vue.js earlier, but the development workflow is so easy with LV, once we got a hang of it.

However, there is one thing we could not find any reference to. We have a huge root layout, and like in the previous Rails application we have it split across several partials. We are using LiveView on top of it, and it works beautifully. Although, the diffs are pretty huge. I figured that LiveView is sending those partials in the diff, probably because it only searches for diffs at the first level, and considers nested partials as updates to simplify diff calculation.

So, e.g. the layout is:

<%= @count %>
<%= render "partials/_nested.html", assigns %>

In the above case, LiveView diffs are returning the whole content of partials/_nested.html. If we remove the partial, and include the HTML in the code directly - the diffs go back to sane size. I guess the same warning applies here - avoid content_tag in your templates.

But, to keep the code DRY - it would be really great, if we can simply ignore such “static” partials from the diff calculation somehow? I am not sure how the diff calculation works (haven’t gone through that part of code). If possible, we would like to mark partials that do not change once rendered, and have them be ignored by LiveView in diffs. Any suggestions regarding this?

:wave:

Have you considered turning the partials into live components?

1 Like

Is your partial a .eex or .leex file?

I know this is quite old but I believe this is what most of us are looking for: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveComponent.html

4 Likes

For folks in the future, I thought I’d also point out that there are both Phoenix.Component and Phoenix.LiveComponent (as @Dlacreme identified). There are some “partial” use cases that might be satisfied by the former. As I’ve seen Component and LiveComponent used interchangeably in some tutorials, thought it worth mentioning.

2 Likes

Don’t use LiveComponents if it’s not really necessary. Use function components instead. IMHO, live component is a new process, so if you have for instance 4 liveview components you have 4 processes, it’s not elixirish!!! and also you could have a headache later passing the properties from one to other.
Also there’s no need to use function component if you don’t use them in at least one other part of the code. So it’s better to use templates like parts of the code in order not to have a spaghetti code.

The question is it possible in Elixir to render just a part of code like template
Example:

... ...
...
<%= render some template of terms_and_conditions.html.heex %>
....

this terms_and_conditions file could have some static variables (constants) for example. But in order not to have spaghetti we decouple it to a separate file

Not true, all live components are part of the same process.

1 Like

To add volume to @D4no0 's comment, LiveComponents are NOT new processes and it’s important to understand that. I do agree, however, to not use a live component if you can get away with a function component. I always reach for function components first then refactor into live components once it starts to make sense to encapsulate some slice of state and behaviour within a LiveView, especially if it can be re-used elsewhere.

Ok, yes, the same process, agreed. My fault. I meant other thing: "They run inside the LiveView process but have their own state and life-cycle. For this reason, they are also often called “stateful components”. Do we always need state?! I say it because there are a lot of tutorials where every time for creating a template or a simple view a live_component is created.