Please don’t forget to post this in the book’s errata as well 
AstonJ
code-shoily
Chapter 1
I completely feel the sentiment presented in the first section, where the complexity of the JavaScript ecosystem and the job description of a front-end engineer is discussed.
In truth, we can’t even show a single diagram of a typical SPA because there are no typical SPAs!
Yes!
Also liked the way LiveView was presented in an ELI5 fashion. One thing though, “Keeping brain in one place” is not something super useful for me. I am cool with context switching, and I believe the back and forth between Elixir and JavaScript a bit more annoying in LiveView (when you have complex enough app) than when you are using SPA, as in that case, you can wear the Elixir or JS hat for longer- making the context switch less, felt.
The rest of it has been mechanical- installation and inspection. I particularly enjoyed the section LiveView Transfers Data Efficiently. And Your Turn happened for me few days ago when checking out @m4hi2’s problem.
The one errata worthy note I found out has been posted already (live_path).
One thing I’d have liked would be, a dedicated section about what LiveView is good for and what are the limitations. And a link to PhoenixPhrenzy contest winners could be sported there (some really awesome apps there if I remember. Also a question, what happened to that site?)
That’s about it. From the perspective of backend engineer and SPA engineer both (who I’d suspect are target audience for this book, i.e. @myself) this is great introduction, interesting enough to look forward to chapters.next!
My apologies for late review, certain personal issues needed dealing but I’m back now and will soon post Chapter 2 review.
Thank you everyone for your reviews.
4
Hallski
Chapter 3
Completely agree with @Tbobbe, a quote I noted down as well:
I also, really enjoyed the chapter and it gave a nice background to the structure of a Phoenix application that have been a good reminder to me. The separation of boundary and core layer was really nicely described. If someone wants to dig more into this separation, it has also been explored by Gary Bernhardt as “Imperative Shell, Functional Core” in [1] and Andy Matuschak as “Object Layer and Value Layer” in [2].
[1] https://youtu.be/yTkzNHF6rMs?t=900
[2] https://youtu.be/rJosPrqBqrA?t=1488
6
wn.dvs1
Good afternoon, dr.a. I have been spending the last weeks trying to fix a live route issue to know avail and was about to abandon my goal to master LiveView. Since I have been retired for 15 years from the University of Illinois at Urbana-Champaign, I have not been actively maintaining a website where I post my papers. My email is wn.dvs1@gmail.com. If you send me your email, I will send you one of the papers. My name is Wayne Davis and I offered years of advanced tutorials in discrete-event simulation. What a porposed that an entirely new paradigm for discrete-event simulation is needed, abandoning the stochastic queueing networks which have outlived their effectiveness.
2
Hallski
Chapter 4
I have to admit I struggled to get through this chapter, it’s quite dense, goes through a lot of generated code and often defers concepts to later chapters. While I personally would have liked having this chapter later, after those concepts had been described I can see the appeal for those that just want to get up and running building their own app.
Good thing I signed up for a book club to keep me motived to power through! 
My main take aways from the chapter in no particular order:
- Learning a bit more about
useand the way that theMyAppWebmodule was constructed to allow foruse MyAppWeb, :router. - A single LiveView handles different states through
live actions. - Function components vs Live components, looks similar to “Presentational” vs “Container” components in React.
- That the core components are generated and put in your application to be modified as you need, rather than learning how to override them.
Onwards to Part 2!
4
Mostalive
Hi, I read chapter 1 thru 5 during the easter holiday, then it took some time to get around to actually write some code. I also read ahead a bit - I would have preferred some testing to be covered earlier than chapter 10. I’m keeping the tests green as I go.
I like the emphasis in chapter 1 on giving an understanding on how the lifecycle works (including the network views, although finding the exact view based on the description involved some fiddling around). As well as the emphasis on design / separation of concerns.
That, combined with having done the phoenix guides, was (I thought) enough to get me started on an experiment to see if I could rebuild an existing application. In hindsight chapter 7 (form components, which also deals with relations) and chapter 10 (testing) would have been useful. It’s not always easy to be patient :-).
I’m also reading through ‘Elixir in Action’ - saves some guessing what the difference between def and defp is ;-).
I like the focus on interactivity in part 3 (dashboards, presence). Not sure about part 4 - from skimming it, it seems to go front-end only with hardcoded data (I’ve burnt myself with hardcoding too much recently).
1
bolducp
Hi Tbobbe! I’ve just started working through the book and am finding your comments incredibly helpful. Thank you! You don’t by chance have a github repo where you’re working on this project, do you?
2
Tbobbe
Hi @bolducp!
I’m very happy you have found my comments helpful 
Sorry to disappoint, but I haven’t got any repo for my code. Although, the only changes I’ve made to the code from the book are the ones I’ve mentioned in my comments
Hopefully I can continue reading the book soon, thank you for the extra motivation!
2
pillaiindu
I’m at page 95 in the book where the greeting is assigned to socket. The book shows the following code,
def mount(_params, _session, socket) do
{:ok,
socket
|> assign(:greeting, "Welcome to Pento!")
|> stream(:products, Catalog.list_products())}
end
What if I write it like the following instead? It looks a bit simpler and more readable, even if I like pipe operator in other places.
def mount(_params, _session, socket) do
socket = assign(socket, :greeting, "Welcome to Pento!")
{:ok, stream(socket, :products, Catalog.list_products())}
end
Is there any added benefit of assigning greeting to socket inside the :ok tuple? Or botht he codes are the same functionality and performance wise?
0
BradS2S
I’d say the difference between the two is readability. Setting up things in a pipeline when you can is more idiomatic.
0