Organizing LiveView

Let’s think through the design considerations for our survey. We may eventually want to display the survey in several different places on the site. You could imagine, for example, wanting to place just the product rating portion of the survey on the show page for a given product or just the demographic details portion on some user profile page. And, as we’ve seen, the dynamic nature of the survey represents a decent amount of complexity.

Both of these considerations push us toward components. Having a dedicated place to put the code related to each portion of our survey will allow us to share these concepts across the site. Also, we’ve said before that great software is built in layers, and components are ideal layers for the LiveView because they help us compartmentalize the markup of our survey sections and the state of each of those sections. LiveView components are the perfect fit to meet the requirements of reusability and complex state management.

Let’s look at what a component is under the hood and how it fits into a LiveView.

How components breakdown LiveView markup and state

When you’re building applications with pure HTML, it’s relatively easy to share code. HTML is a string, so composing with them is straightforward. LiveViews are different. A single LiveView combines the ideas of state management, HTML rendering, and event handling. We need a more sophisticated strategy to compose code with them beyond the typical ideas of helpers and templates, which can’t do much more than wrap up sections of HTML. This leaves a space in the design.

Components step neatly into that space. You’ve already seen that a component is a way to build LiveViews in layers. Each layer maintains its markup, state, and events. In a component, we establish a state, express what happens upon a render, and process events. LiveView takes care of the rest.

Components, therefore, allow us to break down all of the functionality of Live-View into smaller sections that are composable and reusable.

Component process sharing

Components run in the same LiveView process as the parent LiveView in which they are rendered. That means the parent LiveView manages the overall state of the survey, and each LiveView component manages its markup and handles the state for the individual part of the view it represents.

For our survey feature, a parent LiveView will manage the state changes related to the overall survey. Individual components will handle the markup details and manage the state of the individual survey sections—the demographics section and the product rating sections.

Now that you have a little more background on what components are and how they function, we can get to work. We will generate a context to build the base model, one that will let us manage the surveys.

Then, we’ll build a frontend that leverages components to let our users do what we want. Let’s get rolling.

OTP, LiveView, and Components

Components run on the same OTP server as their parent. There’s one shared state and one supervisor. That means error and failure handling all happen at the level of the parent’s LiveView. If you don’t know what these details mean, don’t worry about them for now. Make a note to yourself to study these concepts later if they interest you.