PhoenixLiveViewExt.Listiller is out

This is what I had to do last project.

I would love to see a compare and contrast in your documentation.

Vanilla phoenix code and diffs for the mentioned actions and your extension, diffs for the same actions.

The results are UC dependent and may vary dramatically. For instance, a table row insertion with Listiller will have LiveView send just the particular row to the JS client while a vanilla implementation will replace the entire table. The more rows and columns, the greater the difference.

In my project where I extracted the library from, the average performance gain is typically around 75% to 90% for the vanilla JS side patching alone (i.e. its 4 to 10 times faster). Meaning that with bigger models and slower internet connection this can easily go well over 95% i.e. 20-40 times faster than the vanilla implementation.

As for some hard benchmark results, it would first require building an example app for I can’t publish my real project.

Your documentation on hex is in a self-pointer state. I see more when I open the source in Github.

Definitely, a small demo required to show off the updated_sort capability maybe?

Otherwise, I think I have achieved the same minimum wire transfer with usage of

temporary_assigns
phx-update=prepend
update(socket,)

or am I misunderstanding the component?

To tell you the truth I don’t know what you mean by either of the two questions. I tried figuring out what this Elxsy demo was about and the only link to github was to a certain ykurtbas account where no library similar to mine was published but some other unrelated stuff.

As for your question regarding the temporary assigns and phx-update=“prepend” or “append”, yes, that’s the foundation on which my library is based, but your assigns won’t get diffed server-side and sorted + deleted clientside all by themselves, which is why I made this library. Also, my library runs in a real project relying on thousands of nested fully editable and movable LiveComponents within the lists of other such LiveComponents.

To achieve this effect of a freely editable lists and nested lists you need to handle the sorting (repositioning) and deletion and prior to that you need to prepare the assigns in relative to the operations that you’re doing (depending on your diffing of the assigns, not LiveView’s), unless the only function of the list is to keep on growing in one direction.

The docs are all on hex.pm and if you follow the route below, you get to the Listiller documentation easily:
PhoenixLiveViewExt — phoenix_live_view_ext v1.2.2 → Modules → PhoenixLiveViewExt.Listiller → Top

A new minor update of the PhoenixLiveViewExt is available.

It now supports defining a different function name for the MultiRender macro generated render/2 function.This is useful to avoid render/2 naming conflicts when using MultiRender with a live view or view module.