This is a thread to note down things/best practices encountered in LiveBeats App as I explore the source code.
Found this usage of rescue/1
I’ve been meaning to handle Ecto errors myself. So this comes in handy for next time.
This is a thread to note down things/best practices encountered in LiveBeats App as I explore the source code.
Found this usage of rescue/1
I’ve been meaning to handle Ecto errors myself. So this comes in handy for next time.
Nice exercise @TwistingTwists
This has conn.assigns.current_user
- without worrying that current_user
might not exist.
above is possible because of plug :fetch_current_user
here → https://github.com/fly-apps/live_beats/blob/master/lib/live_beats_web/controllers/redirect_controller.ex#L6
https://github.com/fly-apps/live_beats/blob/master/lib/live_beats_web/live/live_helpers.ex#L494
Never seen a for loop like this before.
https://github.com/fly-apps/live_beats/blob/master/lib/live_beats_web/live/profile_live.ex#L22
https://github.com/fly-apps/live_beats/blob/master/lib/live_beats_web/live/profile_live.ex#L25
“switch_profile” is in player_live.ex
https://github.com/fly-apps/live_beats/blob/master/lib/live_beats_web/live/player_live.ex#L208
matching if current user is same as profile user or any other case.
https://github.com/fly-apps/live_beats/blob/master/lib/live_beats/accounts.ex#L93
I think I should write @docs in a forked repo instead, no?
First of all, thank you for this initiative!
https://github.com/fly-apps/live_beats/blob/master/lib/live_beats_web/live/live_helpers.ex#L494
Never seen a for loop like this before.
I’d recommend to post a “permalink” to the line in the commit. That file was changed 7 hours ago. And looks like the link doesn’t point to the place you meant to.
Protip: if you press Y while seeing a github file it replaces the url at the address bar with a permalink so you can copy that instead of scrolling and clicking copy permalink
Will take care.
Added comments in this forked repo for consistency!
Excellent thread. Pinging @slouchpie so we can comb through this lots of good nuggets!
for a for {key, %{metas: metas}} <- presences, into: %{} do
what does into:
do?
as explained by @kartheek - from elixir-lang
must remember : A comprehension is made of three parts: generators, filters, and collectables.
it collects into %{} in this case
The codefrom live_beats app is transforming presences - adding users and meta to every key in the presences. Final result will be %{key1 => %{metas: <..>, user: <..> }, key2 => %{metas: <..>, user: <..> }}
Can someone explain this link
component?
<.link> defined here has a method={:delete}
which is using this definition here (as I understand so far) .
:delete
work?:sign_out
in href
?Worth noting nested for loops and :reduce
/ :uniq
options too
# psuedo, may be incorrect
for bar <- foo, bazz <- bar, !is_nil(bazz) && !is_nil(bar), reduce: [], uniq: true do
acc -> acc ++ [bar + bazz]
end
This function executes rendered JS commands
Check out the Phoenix.HTML docs for Link.link/2
– You can override the default (:get
) link method. You can also provide a data-confirm
attribute to prompt the user before following the link. This is all ancient UX stuff that you get when you include phoenix_html.js
.
Almost certainly, but take a look at router.ex
to be sure. You don’t want to put destructive actions behind a GET
method (especially a public one) otherwise any request to the path will trigger the destructive action. Imagine a search engine spidering your delete links– it’s not ideal.
I do read the documentation in the cdoe. But what does attaching two modules mean? I see the code is using :telemetry
to perform attach and execute handle_execute
.
I am not well versed with :telemetry
hence unsure about whats’ happening.
handle_execute
broadcasts messages. via PubSub
. Then why do we need telemetry
?
@mcrumm @chrismccord please?
Going through this LiveBeats code has been very helpful!
I have a question on memory management. For assigns created in a mount function, it’s simple to use temporary_assigns to clear data that doesn’t need to be tracked.
But what happens when within a LiveView, you create assigns in your HEEX template? For example, within the ProfileLive render function, there is the following code:
<.icon name={:code}/>
.icon
is just a standard Phoenix component. Obviously it’s trivial in the case, but is the name
assign now in memory being diff tracked with no way of having it cleared from memory since it wasn’t set in the mount
function?
Reading through the docs now, my understanding is that it is diff tracked (and hence saved in memory).
So maybe for big chunks of data that don’t need to be tracked, best practice is to set in a mount function (and release with temporary_assigns) or pass it as a slot?