The LiveView Lifecycle

Before we build our first LiveView, let’s take a deeper dive into the LiveView lifecycle. We’ll go through how LiveView manages the state of your single-page app in a data structure called a socket, as well as how LiveView starts up, renders the page for the user, and responds to events. Once we understand the LiveView lifecycle, we’ll be ready to build out this lifecycle and use it to manage the state of our own LiveViews.

We’ll begin by examining how LiveView represents the state via Phoenix.LiveView.Socket structs. Understanding how the socket struct is constructed and updated will give us the tools we need to establish and change the state of our LiveViews.

Holding state in LiveView sockets

LiveView manages state in structs called sockets. The module Phoenix.LiveView.Socket creates these structs. Whenever we see one of these socket structs as a variable or an argument within a LiveView, we should immediately recognize it as the data that constitutes the LiveView’s state.

Let’s take a closer look at a socket struct now.

Open up an IEx session for our application by typing the following in the terminal below:

Once the server is running, press Enter on your Keyboard, then build a new socket by typing the following command:

Connect to the terminal in the following widget and type the previously mentioned commands.

Here, we can see the basic structure of a socket struct and start to get an idea of how socket structs represent a LiveView state. The most important key, and the one we’ll interact with most frequently in our LiveViews, is assigns: %{}. That’s where we’ll keep all of a given LiveView’s custom data describing the state of our SPA.

Let’s talk about how LiveView establishes that state in the first place and renders it.

Rendering the LiveView

The LiveView lifecycle begins in the Phoenix router. That is where we will define a special type of route called a LiveView route or sometimes live route. A live route maps an incoming web request to a specified LiveView so that a request to that endpoint will start up the LiveView process. That process will initialize the LiveView’s state by setting up the socket in a function called mount/3. Then, the LiveView will render that state in some markup for the client.

Running the LiveView loop

When Phoenix processes a LiveView request, two things happen. First, Phoenix processes a plain HTTP request. The router invokes the LiveView module, and that calls the mount/3 function and then render/1. This first pass renders a static, SEO-friendly page that includes some JavaScript. That page then opens a persistent connection between the client and the server using WebSockets.

After Phoenix opens the WebSocket connection, our LiveView program will call mount/3 and render/1 again. At this point, the LiveView lifecycle starts up the LiveView loop. The LiveView can now receive events, change the state, and render the state again. This loop repeats whenever LiveView receives a new event as this figure shows:

Code structured in line with this flow is simple to understand and easy to build. We don’t have to worry about how events get sent to a LiveView or how markup is re-rendered when a state changes.

Now, It’s time to put what you’ve learned into practice!