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:
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?
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)}
end
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!
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.
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.