P234 Spelling:
“…that sends a message from some other area of you application…” you should be your
P237 Suggestion:
“…The configuration sets the default adapter, PubSub.PG2. This adapter runs on Distributed Erlang––clients across distributed nodes of our app can subscribe to a shared topic and broadcast to that shared topic, because PubSub can directly exchange notifications between servers when configured to use the Phoenix.PubSub.PG2 adapter…”
This could do with more explanation. It assumes a considerable amount of knowledge outside that covered so far in the book. If a reader doesn’t have this additional knowledge, they will not be able to understand what is being said here - which is pretty key to what we’re about to do.
P239 Commentary on send_update/2:
As far as I can see from Elixir docs, there is only a send_update/3 function (where the first parameter is a PID which defaults to self() if not specified and the id: is a component mounted within the live view sending the update). I assume this is what is meant?)
P240 - Suggestion
"…Once send_update/2 is called, the component updates with any new assigns passed as the second argument to send_update/2,…
t took me some time, and reading of the Elixir docs, to realise that we’re not actually sending any meaningful update as part of the second argument, just the id: (which is required by send_update anyway) and that we’re relying on the fact that preload and update will re-query the database and thus pick up the new data.
It might be worth being more explicit about this. At first I was a bit thrown by the fact we didn’t seem to be passing anything of interest - and it wasn’t clear to me that we could have send another assign as an informational payload, but we chose not to do so as in this particular case, it is unnecessary.
P240 Suggestion about the age_group filter code snippet and explanation:
“…That’s the age_group filter…”
he assign_age_group_filter(socket) remains unchanged.
We introduce a new assign_age_group_filter( %{assigns: %{age_group_filter: age_group_filter}} = socket)
It’s not clear whether we are supposed to delete the other assign_age_group_filter(socket, age_group_filter). I established that we’re not - the code doesn’t compile if we do.
It would be useful to make clear that all we are doing here is introducing a new version of assign_age_group_filter (i.e. assign_age_group_filter( %{assigns: %{age_group_filter: age_group_filter}} = socket) ) and that the two existing versions remain unchanged.
P241 Suggestion:
“Next up, we’ll build a section into our dashboard to track user activity…”
Before we move on, it might be useful to show a way of testing this. Can we log in twice as userA and userB, have UserA looking at the dashboard and userB submitting a survey?
From here on, I will refer to things being “in the code”. By “the code” I mean the code in the zipfile (downloaded today, 8th April 2021 at 09:16 UK time) for the “interactive dashboard” folder. I have assumed this code is the “final” interactive dashboard code and as such, should not have any of the “distributed dashboard” code in it - so we can use it as a starting point to “code along” with the Distributed Dashboard chapter. As can be seen from the comments below, that is not always the case. Some, but not all Distributed Dashboard code was present in this Interactive Dashboard code.
P243 Mix up in the code in the zip file
“…So far, there’s not much happening, but let’s call out the details…”
There appears to be much more than this in the code for the interactive dashboard chapter (i.e. which should be the starting code for this chapter). Specifically, the track_user function appears in the code, whereas we’re told to “add” it to the code many pages beyond here on P247
P244 - lib/pento/application.ex module is already present in the code
P244 Mount/3 code is already present
.“…So, we’ll update our mount/3 function in lib/pento_web/live/product_live/show.ex to grab the token from the session and store it in socket assigns, like this:…”
It was already there
P245 Handle_params multiple comments:
alias PentoWeb.Presence
alias Pento.Accounts
are not in the code (correctly)
product = Catalog.get_product!(id)
maybe_track_user(product, socket)
Similarly, these two lines - Product and maybe_track_product - are correctly not in the code
|> assign(:product, product)}
appeared in the code as:
assign(:product, Catalog.get_product!(id))
Finally, neither of the maybe_track_user definitions were in the code
P247 - track_user/3 is already in the code
P247 error:
"…Notice that we’ve also moved the call to Accounts.get_user_session_by_token/1 into this new Presence module function…
It’s actually Accounts.get_user_by_session_token(token) in the code
P248 maybe_track_user multiple comments:
%{assigns: %{live_action: :show, user_token: user_token}}
VSCode syntax checking was unhappy with this, complaining for if connected?(socket) that socket was undefined.
changing the %{assigns: … line to:
%{assigns: %{live_action: :show, user_token: user_token}} = socket
stopped it complaining
Presence.track_user(self(), product, socket.assigns.user_token)
Needed to remove the socket.assigns prefix to stop VSCode complaining about unused user_token (in the %{assigns…. line above)
def maybe_track_user(product, socket), do: nil
VSCode complained that product and socket were unused. They needed underscores.
At the end of this, the code I ended up with is:
def maybe_track_user(
product,
%{assigns: %{live_action: :show, user_token: user_token}} = socket
) do
if connected?(socket) do
Presence.track_user(self(), product, user_token)
end
enddef maybe_track_user(_product, _socket), do: nil
P250 - Browser sessions:
“…Open a few different browser sessions for different users…”
In my case, on MacOS, these needed to be entirely different browsers (i.e. Safari, Chrome, Firefox) or incognito sessions within chrome.
Otherwise, it was not possible to log in as different users.
