Hmm, why almost no one discusses Telemetry stuff? Not-so-trendy but still very useful and improves the whole ecosystem, making it more production-friendly.
thousandsofthem
tmbb
Maybe people are more interested in improving the development complexity in there own app instead of something abstract like “improves performance monitoring for the whole ecosystem”? I certainly am 
1
tmbb
This is where gutting and extracting parts of the Drab EEx engine might be helpful. From what I remember it’s quite efficient at updating only the minimal tree branches that change. The implementation is more complex than just “render everything and send it down the pipe”. Rendering everything is usually very efficient, because IOLists reuse static parts of the template, it’s the “send it down the pipe” that could be optimized.
Another approach, which I suggest is the following:
- cross-compile the EEx template into a javscript function which takes the dynamic substrigs as arguments (not the arguments to the template function!). For example:
Hello <%= @username %>! How are you? It's been <%= @idle_days %> since we've seen you!
compiles into:
function renderFromDynamic(dynamic) {
var fullString = "Hello "
.concat(dynamic[0])
.concat("! How are you? It's been ")
.concat(dynamic[1])
.concat(" since we've seen you!");
return fullString;
}
At the same time, compile the EEx template into something that only generates the (already escaped) dynamic strings. From what I knwo about EEx templates, this seems very easy. In the case above, compile it into something like:
def render_dynamic_parts(conn, assigns, other_args) do
[~e(<%= @user %>), ~e(<%= @idle_time %>)]
end
Then, each time the state changes, send only the dynamic parts to the client (s a JSON array of strings; JSON arrays are reasonably compact), and have the above Javascript function above render the full string on the client and diff the result with morphdom or something else.
This has a number of advantages:
- You can use normal EEx templates (no need to parse the EEx template with something like Floki, like Drab does; from the server’s point of view it’s all strings)
- The server doesn’t deal with the DOM, which is slow and needs to be serialized (let the browser deal with that; it has to deal with it anyway), only with IOLists, which are fast
- You save bandwidth because you only send the dynamic parts
0
blatyo
Conduit Core Team
I’m very excited about this. I’m interested in building integration with this for conduit. I think maybe it’s more library authors that are interested in this than individual users right now. I suspect once it’s more widely used in the community, people will start opening issues/PRs to their favorite projects to add support.
1
chrismccord
Creator of Phoenix
The simplest approach that we take currently is the client’s input with focus wins, and we never overwrite in such cases. There are definitely areas for us to explore here. Under extreme latency this approach would potentially update blurred inputs with bad values b/w the client push, which would recover but wouldn’t be ideal UX. Some OT or similar approach could work, or at the very least we can track all inputs on a phx_change and never overwrite the inputs until we get an acknowledgement.
Wrt to server diff/vdom optimizations, it’s definitely planned but our first steps are to prove out the user land features. Everything else “just” becomes an optimization story which we can improve as we go.
2
tmbb
I agree with this. It’s very rare that the server will want to overwrite user input, and if it does, you are in a distributed system and should definitely be using OT.
I agree completely. It’s acceptable but far from optimum.
Yeah, waiting for acknowledgement to overwrite input fields looks like the way to go. Waiting for some roundtrips to overwrite is probably always better than messing with the cursor position by overwriting what the user is typing.
0
grych
Creator of Drab
I am going to stop developing Drab, as it is not worth to duplicate the same functionality, and LiveView covers most of the areas which Drab does (Commanders, Living Assigns).
1
grych
Creator of Drab
True.
It is actually modifying the template during the compilation, adding its own markers to the DOM tree and saves which assigns are related to which markers. Thanks to this, it can send only the small parts of the page to be updated.
2
hilko
Would love to see your work on Drab, and/or the lessons you learned from it, applied to LiveView though! Based on the keynote the latter is still very much in (early stages of?) development.
2
tmbb
Your approach makes sense if you don’t want to diff on the client, but if you’re going to diff on the client anyway (using morphdom or something similar), I think my approach of sending a list of HTML strings to the client makes more sense. It’s simpler than Drab’s approach (at the cost of requiring a smarter client, of course), and it doesn’t pollute the DOM with custom attributes as much.
1