Phoenix_live_view: Q: Documentation - Anti Patterns.

[joshchernoff]

I think this maybe a tool that has huge potential to become quickly abused.

As someone who is new to sockets and the patterns starting to emerge from this tool I think it would be great to share opinions for new comers. I realize this maybe a big ask and will inherently take time so I completely understand if this ask never happens, but I thought its still work asking. Thanks again

[josevalim]

We talk about such cases almost always when we have a chance, including in the annoncement: https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript (see the "Client-Side Applications Aren’t Going Away"). However, it is likely that less people will reach to the announcement as the docs get more robust and published, so more reference in the docs are welcome.

For example, a common misuse for LiveView is animations... and one should just use CSS animations for most of those. So a word in the docs can be really helpful.

[jfrolich]

Still not convinced of using LiveView for events and user interfaces. This works well when you are really close to the origin server but if you are geographically far (or high latency connection) the user experience would degrade very quickly. Best use case is updating views that are server pushed anyway or where a user doesn't expect direct feedback.

[chrismccord]

The same argument applies to all apps in general, including GH, so I don't think the issue is specific to LV, and we can handle the solutions in the same way, such as loading states. I agree for extremely latent clients with poor connections, it is a bad fit, but that is not a target for us.

[josevalim]

Exactly as Chris said, the latency limitation applies to all apps receiving
data from the server anyway. There is nothing that makes this problem
inherent to LiveView.

A common argument seems to be that LiveView makes it “too easy to forget
about the latency” but by being a higher level abstraction, LiveView is
also in a very good position to provide tools that handle latency/jitter
issues out of the box, while in other solutions that is always a secondary
concern because it is often up to you to figure out the plumbing. For
example, we have an open issue to simulate latency/jitter coming in next
versions and we also provide classes for handling the LiveView state and
actions.

A lot of the focus up to this point has been on answering “is this fast
enough?”. I am sure that once we get to focus on “does this degrade well?”,
we will be able to find solutions and patterns that will allow developers
to build apps that behave better under high latency compared to ad-hoc
solutions.

[jfrolich]

Great. Especially for having a path to upgrade apps that are server rendered and provide some realtime functionality like dashboards.

I agree that server requests do indeed always have latency, but if you handle logic on client side, you can do things like an optimistic response, so that the latency is not perceived by the user. Also LiveView might encourage trivial stuff to happen on the server like clicking a button to show a menu.

Wild idea. Would it be an idea to compile LiveView to React (templates) + GraphQL subscriptions (communication)? Then it would be possible to upgrade the user experience by hand (eject) when necessary.

Anyway love this innovation! And looking forward to how these issues are solved!

[josevalim]

I agree that server requests do indeed always have latency, but if you handle logic on client side, you can do things like an optimistic response, so that the latency is not perceived by the user.

You can achieve similar behavior quite neatly with LiveView because any change that you do after clicking a button will be undone on the update. So it is straight-forward to do something like: click a button and enter into a loading state and the loading state is automatically undone when the update arrives. So we can provide feedback to the user on the client side as we wait for a reply and we will put more emphasis on those transitions as we move forward.

The other thing regarding latency is that with LiveView we can reduce the amount of data sent over the wire thanks to the diff-tracking mechanism (and the upcoming serializer) and maybe even reduce latency altogether. For example, with a regular AJAX request, you have to do a HTTP request, then authenticate that request on the server, load the data from the database, etc. With LiveView, you have an established connection, so you skip the authentication and a lot of the data-loading on every action, so for a moderate latency, the application may be more responsive because there is generally less work to be done. This would of course have to be measured but it is a point worth considering.

Also LiveView might encourage trivial stuff to happen on the server like clicking a button to show a menu.

We will document anti-patterns (which is what this issue is about) but as with any other tool it will be misused despite the amount of warnings we put in place.

Wild idea. Would it be an idea to compile LiveView to React (templates) + GraphQL subscriptions (communication)?

I don't see anyway it could work as it would require us to somehow compile Elixir to Javascript (because the logic would be written in Elixir).

[jfrolich]

You can achieve similar behavior quite neatly with LiveView because any change that you do after clicking a button will be undone on the update. So it is straight-forward to do something like: click a button and enter into a loading state and the loading state is automatically undone when the update arrives. So we can provide feedback to the user on the client side as we wait for a reply and we will put more emphasis on those transitions as we move forward.

Not what I mean, optimistic updates is not about showing a spinner, but to update the UI before the update comes back from the server optimistically so there is zero latency.

I don't see anyway it could work as it would require us to somehow compile Elixir to Javascript (because the logic would be written in Elixir).

No I don't mean compiling the server code to javascript, but

1. Emit react elements instead of HTML (this is just a simple data structure, or some other abstract data structure that the client can transform to react elements) - perhaps some of the diffing logic could then be handled by React. Another step would be to eject templates to JS, so they can be customized client side, but indeed then you'd have to convert elixir code to javascript. Usually within templates is mostly conditionals and loops, so it might be even not an impossible task to do this for most use-cases. But in the simple scenario, you just rewrite a component in JS that needs more refined client side logic.

2. The interface between the client and server as GraphQL subscriptions instead of an opaque interface, so it's easy to take more control @ the client. GraphQL subscriptions are nicer, because they are more declarative than raw web sockets, but this can also just be a public websockets API or higher level javascript API to consume live-view events.

With the right hooks in place, this would allow to use javascript to upgrade the UX where it makes sense. It also allows to go from a mockup to a single page application without rewriting the whole app

Just spreading some ideas about a way for transitioning some logic to client-side as someone writing Elixir/React/GraphQL apps, it might be a nice marriage as live view is basically React's model but server side. If they would be compatible, you can build apps that take different trade-offs wrt server side or client side with the same stack.

[josevalim]

Not what I mean, optimistic updates is not about showing a spinner, but
to update the UI before the update comes back from the server
optimistically so there is zero latency.

Good because I also mean the second. :D What I meant by transient state is
that even if you update the UI optimistically, in many cases if connection
is not available or if the update ends up failing, you also want to show
that to users after some time, but eventually fix it once the update is
properly acked (the iMessage unsent message being a good example).

--

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D