Hello everyone,
I am currently working on a web application that should run smoothly on as many devices and browsers as possible, especially older ones and those with a poor internet connection. To achieve this, I want to avoid using LiveView as much as possible. I plan to use LiveView only for an autocomplete input field and for password strength validation within a (dead) form. However, everything else should be implemented using the traditional (“old”) approach with controllers and DeadViews.
Although I haven’t used LiveView extensively yet, I was able to quickly implement the desired form in a prototype – but only as a fully LiveView-based form. Is it even possible to integrate just single input fields as LiveView (e.g., the autocomplete input field) within a “normal” (non-LiveView) form?
I have little experience mixing both technologies and hope you can help me with this. So far, I have used AlpineJS and a custom-built RESTful API for such autocomplete input fields.
Thank you very much!
1 Like
Liveview renders the HTML on the server so the load on the device is the same if you use deadviews or liveview.
For a poor connection (slow) you are probably still better off with liveview since there is less overhead when using a websocket that sends diffs compared to a full page reload.
I think you are worrying about the wrong stuff. If you want to try this for yourself find a nice liveview page, as an example https://peek.com (not affiliated) and limit your connection speed in your browser dev extension.
That’s not correct as it stands. Yes LV builds the html on the server, but it only sends a minimal diff to the client, which is applied on the client side using morphdom. That second part still requires a certain amount of resources from the client.
Liveview renders the HTML on the server so the load on the device is the same if you use deadviews or liveview.
Sorry, that may not have come across quite correctly, but my concern is less about resources (CPU, RAM, etc.) and more about the fact that the target audience often uses old computers with outdated browser versions and lacks a stable internet connection. As a result, they often switch to their own (unfortunately also outdated) smartphone.
You are, of course, correct. However, I somehow can’t imagine that rendering the entire HTML (that was sent to the browser when navigating around) is less resource intensive on the client that morphing the existing DOM using morphdom?
In any case, unless you are talking about ANCIENT devices, or you are trying to render 10’000 divs we are talking about micro-optimisations.
The concern is valid.
I had to backpedal recently on a contract where my client’s assumptions about their own clients capabilities were deeply wrong. Greenfield browsers and fiber links were assumed whereas the reality was deeply outdated browsers and super-intrusive corporate firewalls.
I migrated liveviews to simple views and form submissions because the user terminals were simply too adversarial. Only the admin views were kept as liveview because higher-ups in those companies had decent hardware and less filtering.
There are settings where our idea of “recent” as developers gets really challenged. Today’s internet must be truly tough to navigate for those users.
I feel so sorry for you and your team… (im not being sarcastic).
It’s okay, the project itself was not very big and we got this feedback quite early. This was a case of overly optimistic specifications. But corporate IT can be impressively outdated.
1 Like
If not actively hostile. A bit back I had a client, which needed to have our domain whitelisted to be allowed to open websocket connections.
2 Likes
Yes, same with the IT in the public sector. 
Especially here in germany: “Why do we need computers, when we can use a fax?”
But back to my question: Is it even possible to use a single autocomplete input field as a LiveView within a DeadView form? If so, how? 
1 Like
Technically yes, using live_render. But you might need to write a hook to get access to input/change events given they are usually captured at the form level for LV.
Does it work with the name of the input field? Is it then necessary for live_render to pass the changeset as an entry in the session in order to use it with the input?
