What will you be doing with LiveView?

So #liveview has been out a little while now, I’m curious, what will you be doing with it? How have you been using it? :101:

1 Like

I really like the potential for multi-step forms.

At Pigeon SMS we have a somewhat complicated sign up process that involves verifying email, verifying ownership of a phone number, etc. We’ve kept the sign up manual because of some of the challenges making our signup automated while keeping friction low.

LiveView is a game changer and we have been working on an automated signup with a multi-step form flow. It has been a delight to develop in and we plan to release it in a few weeks.

I love #liveview!


This is exactly what I am trying to use LiveView for!

Any tips on how you implemented this?

1 Like

I’m planning on doing a blog post or writeup. Stay tuned!

The LiveView module has the base template (title, next/prev buttons, etc.) and inside that base template, a step template is rendered. The path to that step template is stored as part of the state in LiveView. This is rendered dynamically with something like this.

<h2><%= @steps |> Enum.at(@step) |> Map.get(:name) %></h2>
<%= Phoenix.View.render AppWeb.PageView, @steps |> Enum.at(@step) |> Map.get(:location) %>
<button type="button"  phx-click="back" >BACK</button>
<button type="button"  phx-click="next" >NEXT</button>

Step is just an index value. Steps looks something like this:

steps = [
        name: "Basic Info",
        location: "signup/steps/basic_info.html"
        name: "Confirm Email",
        location: "signup/steps/confirm_email.html"

Next function would be something like this:

def handle_event("next", _value, socket) do
 {:noreply, assign(socket, step: socket.assigns.step + 1)}

Thats just a small piece and doesn’t account for the first or last steps (prevent overflow to a step that doesn’t exist), but the general idea.


Thanks for this, really helpful.

I am thinking of something slightly different but in the same vein as a multi-step form.

It’s basically like an onboarding flow that asks you one question at a time. Each question builds on top of the previous one until you get a view where you can edit everything at once in an interactive table.

The other thing is, this onboarding flow is multi-player. Users on the same form can see each other typing and using this form in real-time. If one person answers the question everyone sees the form advance. Because it’s group-based/collaborative problem solving.

I am working on this right now so still a lot to think about. Will share my approach when I have it!

1 Like

Yes, really useful use-case!

Have you thought to use a state machine, gen_statem? I thin it can be really useful for this. With a state machine is possible to handle different complicated forms, with multiple scenarios and different paths.


Interesting! Is there a video demo or tutorial of some kind I watch? It’s a little hard for me to grok how to use this for complicated forms with different scenarios just based on the documentation. I have been trying to conceptualize my idea as a state machine, but there’s a lot of complexity associated with it and if I can use a plugin to help manage the complexity that would be awesome.

1 Like

For gen_statem take a look at this article: Persistent connections with gen_statem, it has been my first read about this module (I still have a lot to learn about it … I’m trying atm to use it in the LV app).

I’m writing a sample app + article on that. Let me know if you are interested, I’ll send you the link once ready.