![]() ![]() This could include user navigation dropdowns, expanding menus, etc. Imagine we want to toggle a container in our layout. Let’s explore a couple of use cases to see how we can get the best of both worlds with LiveView and client-side code while optimizing for user experience. LiveView allows developers in large part to free themselves of client-side concerns, but the fact we can execute code on the client is not only necessary for LiveView to exist, but an asset for developers to lean on when they require a JavaScript escape hatch for client-side interactions. Next, we’ll explore concrete examples of client-side solutions within a LiveView application. ![]() These basic UI feedback features are a great starting point, but sometimes more interactivity is required which can only be achieved on the client. This allows you to trigger your main loading UI states for any LiveView event as necessary. Likewise, once the server acknowledges our event, the CSS class is removed and the phx:page-loading-stop event is emitted. For example, buttons can be annotated with phx-disable-with to swap textual content when a form is submitted:Ĭlicking on this button would apply both the phx-click-loading CSS class and emit the phx:page-loading-start event. LiveView itself ships with a few client-based features that allow you to provide your users with instant feedback while waiting on potentially latent actions. Built-in basics for Optimistic UI and UI Feedback In fact, LiveView includes UI feedback features out-of-the-box to handle common scenarios for you. If you abide by these general guidelines, your LiveView UX will match or beat SPA counterparts because of the data optimizations LiveView is able to achieve, with far less code than a purely client-side solution. Adding items from inventory to a shopping cart.Otherwise, any interaction that necessarily involves the server is a perfect fit to happen in the server LiveView, for example: “controlled inputs” such as autoformatted dates, phone numbers, where a user’s input is translated as they are typing.If the user interaction demands zero-latency, client-side code is the only solution, for example: The toggled content itself requires stateful changes to the backend, such as data subscriptions.The toggled content is dynamically loaded to save either network or application load.If the user interaction is only about toggling content (show/hide, CSS classes, etc), prefer client-side, unless: Follow these guidelines to answer where a client or server responsibility exists in your LiveView projects: For example, while loading dynamic content sometimes requires a trip to the server, formatting a user’s phone number as they type necessitates zero latency or the interaction is a clunky, frustrating experience. ![]() Let’s get started! Client vs Serverįrom a UX perspective, it’s vital to identify which interactions are expected to remain latency-free. ![]() LiveView is a perfect fit for real-time applications like dashboards and feeds, as well as applications with client interactions that necessarily require a round-trip to the server, ie chats, interactive forms, shopping carts, image uploads, etc.īut what about those interactions that don’t require round trips like toggling page content or interactions that demand zero-latency such as formatted inputs? In this post, we’ll see how to identify whether a round trip to the server is necessary and solutions that make purely client-side interactions a breeze to work with inside LiveView. The Phoenix LiveView programming model allows developers to deliver applications more quickly, with feature sets previously only obtainable by single page application frameworks. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |