I think this pattern will be important for LiveView backed forms. From a user point-of-view, losing a bunch of stuff you typed in is a negative experience. However, I’m excited to see what kind of patterns emerge for this.
But while I thinking about this stuff, I’m also not thinking about all the Javascript I would have to write.
I compiled a simple vue component with the webcomponent build target and deployed that within the Demo app web artifacts. In a new LiveView module, I added the custom element markup and socket bindings. Binding the server state into the element works great, i piped in the clock, weather, etc. It works like any other data property and doesnt rerender the entire component.
Unfortunately I spoke a bit too soon. The downside seems to be getting data out of the component. I hacked around the click/submit/change handlers but could not get it to populate the value field of the event passed up the socket. If the wrapper supported CustomEvents (something like. phx-custom-eventname that grabs event.details) then webcomponents could probably work.
Fear not, this is easily doable today 
I have pushed a branch with an example:
Code wise, you can add the dynamic fields with inputs_for like a regular static form:
<%= label f, :hobbies %>
<%= inputs_for f, :hobbies, fn hf -> %>
<%= text_input hf, :title, placeholder: "hobby" %>
<%= error_tag hf, :title %>
<% end %>
<button phx-click="add_hobby">+ Add Hobby</button>
Then in your LV:
# UserLive.Edit
def handle_event("add_hobby", _, socket) do
changeset = Accounts.build_hobby(socket.assigns.changeset, %{title: ""})
{:noreply, assign(socket, changeset: changeset)}
end
That’s it! As long as you update your changeset assign, which is what the validate callback does, then there’s no “either/or” dance as the server has the changeset state. My build_hobby code in this case is just a simple ecto embed, but you can get the idea:
# Accounts
def change_user(user, attrs \\ %{}) do
user
|> populate_hobbies()
|> User.changeset(attrs)
end
defp populate_hobbies(%User{hobbies: []} = user) do
%User{user | hobbies: [%Hobby{title: ""}]}
end
defp populate_hobbies(%User{} = user), do: user
def build_hobby(changeset, hobby) do
hobbies = Ecto.Changeset.get_field(changeset, :hobbies)
Ecto.Changeset.change(changeset, hobbies: hobbies ++ [hobby])
end
Hope that helps! Here is the branch:
https://github.com/chrismccord/phoenix_live_view_example/commit/1181c79955b96e66f2dcdb8357498f6cce8f61fb
That’s brilliant Chris, thank you! I was thinking about it last night (no computer in front of me) and was going to try something similar. Thanks for the example!
Congrats for LiveView great devs! … this seems to be so exciting that if I had the time I was going to start changing lots of JS stuff to it.
However, I am mostly thinking about how to implement the following patterns in LiveView:
I see there is a phoenix_live_view Javascript module with lots of logic in it. Perhaps, if I’m not wrong, the JS architecture can be improved to make it more extensible, by breaking the file into smaller ones so people can reuse parts and add features without having to touch the core …
Anyways, going a little bit deeper, I was reading the morphdom README and found the following sentence:
UPDATE: As of
v2.1.0,morphdomsupports both diffing a real DOM tree with another real DOM tree and diffing a real DOM tree with a virtual DOM tree. See: docs/virtual-dom.md for more details.
This makes me think that in the near future, it might be possible to update a React app with content from LiveView.
Finally, I’d like to know if using GraphQL more specifically Absinthe will make sense instead of accessing the backend directly without the extra layer, in case of using plain LiveView without extra Javascript of course.
This looks fantastic. I’ve been waiting to use this in a project of mine. Huge congratulation to the team.
One question - I modified the autocomplete example to return 200 words and on my box the search ground to a bit of a halt - it did eventually return but was taking seconds to display the results. I appreciate returning 200 words isn’t perhaps a real world use case but wondered why the performance loss?
This is amazing, I remember hearing about LiveViews and then watching one of Chris’ video about it a few months ago and that’s one of the reason I started to look more into Phoenix (as a Rails replacement) as I’m looking more into how to reduce the “SPA for everything” trend.
I’ll look into migrating a simple form I have that uses Ajax to LiveView and see how it goes!
I’ve been thinking about contributing to Elixir/Phoenix - are contribution opened yet? How can we jump on the bandwagon and help?
“200 words” is nothing as far as LV is concerned. Consider the rainbow where we are generating 80 divs every 16ms My hunch is the browser is choking on the <datalist> updates containing 200 options, so my wild guess is it’s a browser issue and nothing in what we’re doing on our side. The datalist thing is somewhat new, so likely not optimized. UX wise, it also doesn’t make sense to render that many options below an input, so the browser’s UI rendering of it is probably not optimized for that case.
Awesome. Let us know how it goes! We tag issues on the phoenix repos as level:starter when they are good opportunities for new folks to get involved without trying to take on the world. We just had our 1.4.2 release so a lot of issues were closed out, but keep an eye on the issue tracker, as this is the best way to get involved. Welcome aboard!
ok, makes sense.
One other question if I may. Is it possible to incorporate LiveView into an existing eex template? I’ve a form which would benefit from typeahead but I’d like to keep the majority of the form in eex with only a specific text box with the typeahead? All the examples seem to isolate the LiveView templates.