Note that mount/3 and render/1 will be called again, this time over the WebSocket connection. The page then opens a WebSocket connection between the client and the server.Īfter the WebSocket connection has been established, we get into the LiveView life cycle: This will render a static page (SEO-friendly out-of-the-box, by the way!), with the required Javascript for LiveView to work. The router will invoke a LiveView module, which calls the mount/3 function and then the render/1 function. The first request made to a LiveView route will be a plain HTTP request. It should be said, however, that this is added by default in new LiveView projects, so if you want to have a setup that’s as close to a freshly generated project, you should include this.Īt this point, you should have everything ready for introducing your own LiveView code! Quick LiveView overviewīefore we get to the actual coding, let’s get at a quick overview of the life cycle of a LiveView page. The only comment I’ll add is that the section at the very end about adding a topbar is (as the documentation points out) optional. The guide is rather straight-forward, so I will not reiterate its contents here. The LiveView documentation has a great section on the subject: Installing LiveView into an existing project. The next step is to install LiveView into your existing project. Here’s the relevant section: Move to HEEx. It is highly recommended to do this as well. ![]() Phoenix 1.5.x to 1.6.0 upgrade instructions In the latter of the two guides, there’s an optional step to change the templates to HEEx.Phoenix 1.4.x to 1.5.0 upgrade instructions.Following are upgrade guides for older projects: If these are not of concern to your use case, then let’s get going! What does it take for me to start? Phoenix setupįirst of all, you’ll want to have a recent version of Phoenix, and your code up-to-date. LiveView ships with tools for testing your application with increased latency, but if you already know that there’s a certain latency maximum that your clients must not but very likely would exceed, then LiveView may not be suitable. This is where Javascript frameworks like React, Ember, etc., shine.”Īlmost every interaction with a LiveView interface will send a request to the server while requests will have highly optimized payloads, if you expect the average round trip from client to server to be too many milliseconds, then the user experience will suffer. “Certain use cases and experiences demand zero-latency, as well as offline capabilities. The second biggest question: do you expect the latency from your clients to the server to be high, and would it being high be a serious detriment to your application?Īs Chris McCord put it in his announcement blog post on the Dockyard blog: The reason for this is that LiveView is rendered on the backend, necessitating communication with it. My guess is that you probably do not need it, but if you do, LiveView is not the technology for you. The biggest question is whether you need an offline mode for your application. There are some properties of LiveView which are inherent to the technology, and therefore must be considered: Offline mode After all: no team likes to adopt a technology that they later figure out does not suit their use case. You might have some worries about whether LiveView is a technology that you can introduce to your application. ![]() I hope that this article may serve you well as a starting point! Will it work for my use case? Tate and Sophie DeBenedetto) may be of more use. If you have the luxury of a clean slate, then other resources (such as the Programming Phoenix LiveView book, by Bruce A. Therefore, throughout this guide, I’ll presume that you already have an existing project that you wish to integrate LiveView into. After all: it’s often not just about learning LiveView as if you were writing a greenfield project, but about how you would add LiveView into that Phoenix app that you’re already working on. However, if you haven’t already jumped into it, you might be hesitant to start. Building interactive frontends, with no Javascript required? This sounded like it was made for all of us Elixir backend developers that were “frontend curious”. This is why I got very excited when Chris McCord first showed LiveView to the world. While the web seemed like the platform with the lowest bar of entry for this, the size of the Javascript ecosystem had become so vast that familiarizing oneself with it was no small task. Nonetheless, I always wanted to have a tool at my disposal for building rich frontends. Whether it’s React/Elm for the web or Swift/Kotlin for mobile, these are fields of knowledge that fall outside of what I usually work with. As a backend developer, I’ve spent most of my programming career away from frontend development.
0 Comments
Leave a Reply. |