Starter Phoenix LiveView Course (Pragmatic Studio) (Free)

[mikeclark]

Thanks, glad you’re enjoying it! I appreciate your continued interest in the course.

I’m aiming to release a new video every couple weeks or so at a sustainable pace. Some examples are more involved than others. Also, each video includes notes and exercises which add to the effort.

Basically, I’m just trying to do my best work on each example and as they’re done I’ll release them.

[mikeclark]

Thanks! It was fun coming up with that line.

[josefrichter]

Great, thank you. I just bought your other Elixir course partially to thank for this free one

[mikeclark]

Thank you! That’s very thoughtful. We appreciate the support. I hope you enjoy the Elixir course.

[trentjones21]

This course is really well done. Just watched video 16 (real-time updates) and it cleared so much up for me. Thanks!

[egze]

I’m not really liking this approach, because you just made your liveview responsible for the validation knowledge. I would move it out to a separated module.

defmodule PorchLight do

  def up(brightness) do
    # your case statement. Or multiple up functions with pattern match.
    # returns updated brightness
  end

end

In the LiveView you just have:

def handle_event("up", _unsigned_params, socket) do
   {:noreply, update(socket, :brightness, &PorchLight.up/1)}
end

You can also make the PorchLight a struct with more complex structure. Anyway, the point is that now you can use this module anywhere, regardless if you are rendring with LiveView, just HTML, JSON or whatever. It can also be tested better in isolation because the function is pure.

[mikeclark]

In general, I agree that it’s better to put the porch light behavior in a separate module independent of LiveView. However, since this is the very first example in the course, we wanted to keep it really simple and focused in one file without any indirection.

You’ll find that in subsequent videos we’re careful to extract this type of logic into separate modules. And as we get into using Ecto, we rely heavily on Phoenix context modules as a boundary layer.

[egze]

Oh, I didn’t mean it as a critique of the course. To teach LiveView it is a perfect implementation. I’m a big fan actually, currently on lesson 11. Huge thanks!

My comment was only in context of how to improve the particular code snippet.

[thojanssens1]

Thank you for those LiveView video tutorials. Those are truly amazing.

One remark: one thing lacking are the dates of the release of each video. Because I can’t know at which pace those are released (i.e. I don’t even know when was the last video released, which makes it hard to take a guess on the next video release).

[mikeclark]

Thanks for your kind words!

You make a good point. We released the first 7 videos in late April, and then generally released a new video every couple weeks. But you would only know that if you were on the mailing list where we sent updates. So going forward I’ll be mindful to give better indications on the course page.

Thanks for the feedback!

Mike

[thojanssens1]

I noticed something weird in page_live.ex.

In the handle_event for “suggest”, there is the following return line:

{:noreply, assign(socket, results: search(query), query: query)}

But I can even type “hello” for :query, like so:

{:noreply, assign(socket, results: search(query), query: "hello")}

And the input field won’t change its text even though its value should come from assigns :query:

<input type="text" name="q" value="<%= @query %>" placeholder="Live dependency search" list="results" autocomplete="off"/>

I could not find a way to programmatically change the input field’s text.

There’s something I miss there…

Print screen:

This is the value of @query: "<%= @query %>"<br>
<input type="text" name="q" value="<%= @query %>" placeholder="Live dependency search" list="results" autocomplete="off"/>

EDIT: not being able to edit while the text input has focus seems normal:

For any given input with focus, LiveView will never overwrite the input’s current value, even if it deviates from the server’s rendered updates.

I actually wonder then if we really need that state :query, I don’t see what it’s for.

[mikeclark]

The page_live.ex file and its corresponding template file are generated by the phx.new generator when you use the --live option. It’s not something we wrote in the course, so I’m not very familiar with it. I see your point. Not sure exactly why it was implemented that way.