
herminiotorres
Programming Phoenix LiveView: Typo
Hi! I know not the intentions behind this narrative when called, on page XI
:
mount() |> handle_event() |> render()
but the correct flow, it’s:
mount() |> render() |> handle_event() |> render()
On page XII
, it’s missing the content about chapter 1.
Marked As Solved

SophieDeBenedetto
Thank you so much for helping by pointing these out! You’ll find most of the fixes applied in an upcoming Beta release. Not the next release, but probably the one after that
Also Liked

froucoux
On page 22 : Finally, we return a tuple in the shape that LiveView expects—{:ok, socket}
Shouldn’t it be: {:noreply, socket} ?

cro
Thanks for the pointer. I had to manually update the dependency versions in mix.exs, mix hex.outdated
gave me what I pasted below. After I did that and ran mix deps.update --all
it cleared up.
$ mix hex.outdated
Dependency Current Latest Update possible
ecto_sql 3.5.4 3.5.4
floki 0.30.0 0.30.0
gettext 0.18.2 0.18.2
jason 1.2.2 1.2.2
phoenix 1.5.8 1.5.8
phoenix_ecto 4.2.1 4.2.1
phoenix_html 2.14.3 2.14.3
phoenix_live_dashboard 0.2.0 0.4.0 No
phoenix_live_reload 1.3.0 1.3.0
phoenix_live_view 0.12.1 0.15.4 No
plug_cowboy 2.4.1 2.4.1
postgrex 0.15.8 0.15.8
telemetry_metrics 0.4.2 0.6.0 No
telemetry_poller 0.5.1 0.5.1

SophieDeBenedetto
Hi there! Thanks for you feedback and questions
- p.75, Ch 1, §“Handle Events”: “Finally, we return a tuple in the shape that LiveView expects—{:ok, socket}.” For
handle_event
I think the tuple has to be{:no_reply, socket}
or{:reply, socket}
?
You are correct! You’ll find this updated in the next Beta release
- p.98, P 1 Ch 2, §“Reducers in Plug”: The second representation of the pipeline using pipe operators still has
plug
in the last three lines, but I think shouldn’t?
Yes I think this example will be more clear with the change you are suggesting. You’ll find it in the next release!
p.71, Ch 1, § “Render the Live View”: Just wondering, since the links you’re rendering go nowhere, if the semantics here aren’t better represented by
<buttons>
? And similarly the<h2>
tag could be replaced by an ordered list?
Great suggestions and I think if I was building a “real” game, cleaning up the code in that way would be the way to go. But the current approach will suffice for this example
Popular Prag Prog topics










Other popular topics










Latest in PragProg
Latest (all)
Categories:
Popular Portals
- /elixir
- /rust
- /wasm
- /ruby
- /erlang
- /phoenix
- /keyboards
- /js
- /rails
- /python
- /security
- /go
- /swift
- /vim
- /clojure
- /java
- /haskell
- /emacs
- /svelte
- /onivim
- /typescript
- /crystal
- /c-plus-plus
- /tailwind
- /kotlin
- /gleam
- /react
- /flutter
- /elm
- /ocaml
- /vscode
- /opensuse
- /ash
- /centos
- /php
- /deepseek
- /zig
- /scala
- /html
- /debian
- /nixos
- /lisp
- /agda
- /textmate
- /sublime-text
- /react-native
- /kubuntu
- /arch-linux
- /revery
- /ubuntu
- /manjaro
- /spring
- /django
- /diversity
- /lua
- /nodejs
- /c
- /slackware
- /julia
- /neovim