Wrapping live components with functional components

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!

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.

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!

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.

1 Like

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.

1 Like

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.

2 Likes

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.

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

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