Posted in the Phoenix LiveView blog posts - #6 by AstonJ thread for you 
For anyone else writing blog posts on LV - please don’t forget to add them there 
I’ve led a 5-7 person group session this week, adding LiveView into our Lucidboard project. (Think Trello clone.) It’s been going just swimmingly and we are very excited to share our newfound superpowers with a wider audience.
Two things that we haven’t worked out yet are (1) drag & drop, and (2) capturing DOM attributes to send along with the event. (We wanted to measure the .scrollHeight of a textarea so it could be expanded to show all its content without scrollbars.) I wonder if we can evaluate evaluate an actual JS expression for these features, if we will need to implement certain things in pure JS using the phoenix_live_view.js APIs, or if there is already some trickery to allow us to solve for these things.
Incidentally, anyone is welcome to pull up a chair and help us out with this MIT-licensed, community effort!
We’re looking forward to exploring further how we can supercharge our projects with LiveView & Elixir! Thank you so much, Chris, José & Co. for your amazing contributions!
That feels like the stuff you wouldn’t want to do with live view as it’s not benefiting from being calculated on the server. You already have all the information on the client to do the job. No need to add latency and involve another party.
This is an entirely valid point of view.
That said, if you measure the value of Live View at least in part by how much basic interactivity you can get without writing Javascript, it would be nice to be able to access parts of the DOM that aren’t tied to assigns. Drab does this, it is very pleasant and has worked fine for me even if it is not optimally efficient.
That said, it feels to me like Live View only allowing DOM updates via modified assigns is a conscious design choice, and as I try to get familiar with it by rewriting a Drab-powered application in Live View, I see how introducing this constraint has advantages, too.
Drab also provides a map of the attributes of the DOM element to the event handler, (the sender map) as opposed to just one attribute (e.g. phx-value). You can work around that in Live View, but unlike the absence of direct DOM manipulation discussed above, I don’t yet see any advantage to this limitation; it’s just kind of a pain (at least from my vantage point of having become accustomed to having it with Drab).
In master we have already changed phx-value to be a map, so we can allow extra data to be given but it is not yet clear how this extra data will be retrieved/computed. Maybe a custom function that is evaluated with the DOM element? But it is unlikely we would send anything extra out of the box.
Sorry, I must be missing something really obvious but I can’t find any examples that point the way to re-usable components.
For example, if I have a page/view with:
<div>
<%= live_render(@socket, DemoWeb.ImageLive) %>
<%= live_render(@socket, DemoWeb.ImageLive) %>
</div>
… each DemoWeb.ImageLive is mounted with the same socket.id, no client events appear to be generated by the second DemoWeb.ImageLive and so the second DemoWeb.ImageLive “doesn’t work”.
What’s the recommended strategy for using multiple identical liveViews/re-usable components alongside one another please? Thanks …
