Wrapping live components with functional components

Phoenix Forum Chat / Discussions
,
1

I have a navbar component that I include at the top of all my live views. Since it reacts differently based on certain attributes passed to it that are loaded in live views, I can’t just stick it in live.html.heex.

So the top of a typical live view render function looks like this:

def render(assigns) do
  ~H"""
  <.live_component
    id="navbar"
    module="MyApp.SomeNamespace.NavBar"
    logged_in?={@logged_in?}
    some_decision_based_on_liveview_assigns={@some_assign_unavailable_in_the_layout}
  />
  """
end

While I’m the type who loves some pretty code, I don’t strive for it at all costs if it hurts clarity. But I also hate noise and this started to feel really noisy. I realized that id and module are always static, so then I had the idea to wrap the live component in a functional one:

def navbar(assigns) do
  ~H"""
  <.live_component
    id="navbar"
    module="MyApp.SomeNamespace.NavBar"
    logged_in?={@logged_in?}
    some_decision_based_on_liveview_assigns={@some_decision_based_on_liveview_assigns}  
  """
end

So now in my live views I can simply do:

def render(assigns) do
  ~H"""
  <.navbar logged_in?={@logged_in?} some_attr={@some_attr} />
  """
end

Other than that it’s hiding away a live component and that it maybe feels a little icky, I’m wondering: are there any drawbacks?

In anticipation of someone quoting that last sentence back to me saying, “That’s what’s wrong with it!”, my thoughts are that I would only use it in this one case where it’s going to be on basically every live view in my app. Maybe calling it <.live_navbar /> would it clear that it’s lying about being functional? :thinking:

I realize this is a bit of a bike shed, but I’m interested in opinions if they are out there, especially if there is some real danger I’m not thinking of.

Thanks!

2

Well this isn’t an answer but FYI live.html.heex has access to all assigns from your LiveView, so you could stick the nav there.

3

No, that is an answer. I did know that but I wanted to avoid having to default all the “special” attrs to nil for the layout. Of course, now that I’m saying that out loud, that’s actually not such a big deal since in my case I only have one—I was really just prematurely optimizing for a scenario I probably will never have. Heh, ok yes, haha, thank you!

1 Like
4

I was pondering my navbar recently and came to the conclusion that it shall be a function component in live.html.heex and it’s brains shall be contained in an on_mount hook.

2 Likes
5

That’s along the lines of one of my thoughts, although I was gonna put stuff in on_mount and still use a live component since my navbar makes database calls using optionally using assigns from the current page (liveview). It felt a little perverse. But ya, I think it’s going to end up having to be in the on_mount callback as since I’ve posted this, I’ve already felt the pain of having to include boilerplate on every liveview I want a navbar on… which is all of them o_O This also means caring about the url in on_mount which is unfortunate but there are worse things in life.

2 Likes
6

Know that you’re not alone in your suffering :wink:. I tried a liveview, a sticky liveview, a layout component that I included in every liveview and a live component. The root level function component + on_mount is the only one that could cater for everything my heart desires. This is indeed how they do it in live_beats.

3 Likes
7

That’s interesting—I’ve never defined on_mount right in a liveview before. I see it’s doing to attach hooks but… I’ll have to dig into that later, and really finishing digging more into LiveBeats.

8

They aren’t defining it in a liveview. This module is called from the live_session, as per these lines.

9

Oh jeez, yes, I have to stop going on elixirforums at the end of my day. Cool cool, thank you!