Application Inventory
Explore how Phoenix LiveView defines user-facing routes as an API, enabling single-page application features through live routes and actions. Understand the roles of generated files in managing product listings, forms, and live components while grasping core workflows for mounting, rendering, and change management.
We'll cover the following...
So far, we’ve spent all of our time on the backend service that manages products in our catalog. We were lucky because we could focus our exploration on a single API, the Catalog context.
In the LiveView, we’re not so lucky. There are nearly a dozen files that we need to worry about. It would be nice to start with a common interface for our user-facing features.
It turns out we do have such an interface, but it’s not an Elixir API. Instead, it’s a list of the routes a user can access. That’s right, the routes in pento/lib/pento_web/router.ex are an API.
Let’s take a look at the LiveView routes we generated in the last few lessons.
How to route the LiveViews
The router tells us all of the things a user can do with products. It represents a high-level overview of how each piece of CRUD functionality is backed by LiveView. Let’s take a look at the routes we added to our application’s router after we ran the generator in the previous lessons. We’ll break down how Phoenix routes requests to a LiveView and how LiveView operates on those requests.
That’s exactly the API we’re looking for. This list of routes describes all of the ways a user can interact with products in our application. Each of these routes starts with a macro defining the type of request, followed by three options. All of our routes are live routes, defined with the live macro. We’ll take a ...