Phoenix LiveView is now... live!

Phoenix Forum Chat / Discussions
,
42

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.

1 Like
43

Yes, see the home page of the examples repo, we have a weather widget on the regular index.htm.eex page.

The form input usecase is a little more complex however, because liveview needs to own the parent form, so in your case, you need to make the entire form the LV template and it will just work via <%= Phoenix.LiveView.live_render(@conn, TypeAheadLive, session: ...) %> in your eex template

1 Like
44

Perfect - many thanks for your help and the awesome work you’ve done on LiveView and Phoenix.

1 Like
45

@chrismccord could you provide a bit more color on how discardError and phx-error-for work?

I’m trying to figure out how LiveView knows whether to show or hide the error and how the data attitude fits in the equation.

Congratulations on the release. Looking very cool :slight_smile:

46

Speaking about JS interop, while I was working on a table editor demo (https://github.com/hurty/phoenix_live_view_example/blob/master/lib/demo_web/live/tables_live.ex) I was wondering how I could focus() a cell’s <input/> after it appears. But as I understand it, it still needs to be investigated…

I really like the Stimulus approach where you have elements automatically connected to JS controllers as they enter or leave the DOM. I think it could be really nice to use alongside LV when some plain JS is needed.

Imagine at some point LiveView renders something like <input type="text" data-controller="focus"/> , you can have this kind of JS controller:

import { Controller } from "stimulus"

export default class extends Controller {

  connect() {
    console.log("focusable has entered the DOM")
    this.element.focus()
  }

  disconnect() {
    console.log("focusable left the DOM")
  }
}

Stimulus philosophy works really great with server-side rendered HTML and monitors the page for you. You can of course reuse the same controller multiple times for different elements.

47

FWIW I did manage to get LiveView to work with Vue web components bidirectionally.

11 Likes
48

We hide a data-phx-error-for container if its input has not yet been focused, as long the form has not yet been submitted.

2 Likes
49

Ah that makes perfect sense. Thanks for sharing, Chris!

50

Hi!
Is file uploading supported by LiveView? I tried to make a small template with the file upload form but there is no Plug.Upload structure in the socket of the handle_event(event, params, socket) callback.

  def render(assigns) do
    ~L"""
    <h3 class>Import</h3>

    <form phx-submit="upload" enctype="multipart/form-data">
      <fieldset>
        <label for="file">File to import</label>
        <input id="file" type="file" name="file" value="">
        <input type="submit" value="<%= gettext "%{name}", name: "Import" %>">
      </fieldset>
    </form>
    """
  end
...

  def handle_event(event, params, socket) do
    IO.puts "event: #{inspect event}"
    IO.puts "params: #{inspect params}"
    IO.puts "socket: #{inspect socket}" # here the socket does not contain Plug.Upload structure
    # i don't know maybe this is the wrong place for this structure
    {:noreply, socket}
  end
1 Like
51

not yet

1 Like
52

Awesome I’ll look into this!

53

Thanks for releasing the incredible LiveView… wow what a difference this will make for my time-to-market.

I was looking at this over the weekend also… in the CRUD new user example I was trying to figure out how to hide the error for email address (and phone number) until first success or first blur. Right now discardError hides the error until you focus and start typing. I’d prefer not to show my user an error when they are just starting to type a valid email address.

It would be ideal if it could start showing errors on that field once it first succeeds (i.e. they type the “@” satisfying the regex which clears the changeset error). So if they complete the field properly then blur they never see an error but if they hit backspace clearing the “@” after first success the error shows up. If that’s not possible then having an option to only show the error onBlur (plus onSubmit) would be great. I was thinking of ways to handle this server-side by doctoring the changeset until receiving a phx-blur event I could handle but that’s not supported yet.

Is there anyway to do this currently or is this planned? No worries if it’s on the roadmap I realize it’s early days but as it stands it’s already very close to handling all my forms with probably 1/5th the code currently required w/React!

54

phx-debounce will handle this, which is coming soon

2 Likes
55

That’s pretty cool, going to look at this.

56

That’s super exciting, thanks for that :+1:t3:

Desktop apps is one area that I think LV have a lot of potential. Latency not a concern (at least not between GUI and embedded phoenix backend). The hard work being done by the BEAM, maybe desktop apps could be great again? Not only saving RAM, but also error handling, supervision, hot updates, all that stuff :slightly_smiling_face:

Just started playing with the example app in Electron. More ideal would be to use Chromium directly, perhaps mozilla’s servo can also become an option.

57

Hi - hoping LiveView can accommodate this. I have a master/child form with the children displayed using inputs_for.

I’d like to use the live_search type facility for each child form (one of the child fields represents a country). Is it possible to identify which specific field the user is currently entering. The changeset obviously contains all changed fields and I can’t see a way of identifying the one the user is currently working on.

Hope this makes sense.

cheers

Dave

58

I have done some tests with LiveView and internet connection issues. It seems that if we have a drop of connection during the fill of a form:

  • it’s not possible to continue editing the form,
  • when the connection recovers, the form is reseted.

We also have some issues with safari that closes websocket on long background state.

I wanted to test the functionality to support a form that my users could edit during minutes. If my understanding is good, if we have any connection issue, my users will not be able to continue the edition and they will lose all the inputs. Am I right?

59

Many thanks for LiveView … congratulations and very much appreciated!

Any chance of an example to highlight component aspects?

eg a view with 2 DemoWeb.ImageLive working independently?

<div>
<%= live_render(@socket, DemoWeb.ImageLive) %>
<%= live_render(@socket, DemoWeb.ImageLive) %>
</div>

… I might be stupidly missing something really obvious, I can see the mechanics but the usage doesn’t seem to be obvious from the docs or examples.

Many thanks and congratulations again.

2 Likes
60

This is already in place in the examples repo, see the thermostat demo:

3 Likes
61

The form disabling is a feature, but I agree we need a mechanism to recover inputs on reconnection, either thru the planned push_session feature or controllable on the client when we patch after reconnect

Sometimes browsers sleep the js thread, so this is expected, but the client should reconnect when you activate the tab. Are you seeing reconnects not happen?

3 Likes