How to build components with a lot of external properties?

[flosse]

If I don't want a local state I have to pass it by the parent component, right?
But it feels a bit messy.

E.g. in TEA you'd define a struct Model { .. } that only holds the state and a enum Message { .. } that defines all events that can occur.

What is the idiomatic leptos / FRP approach?
e.g. how can I make this cleaner?

#[component]
fn Foo<F,B,Z>(
   // --- static data --- ///
    static_prop_foo: bool,
    static_prop_bar: u64,
    static_prop_baz: &str,
    // ... and many more 

    // --- dynamic data --- ///
    dynamic_prop_foo: ReadSignal<FooData>,
    dynamic_prop_bar: WriteSignal<BarData>,
    dynamic_prop_baz: RwSignal<BazData>,
   // ... and many more 

    // --- event handlers --- ///
    on_foo: F,
    on_bar: B,
    on_baz: Z
   // ... and many more 
) -> impl IntoView
where
    F: Fn(FooEvent) + Clone + 'static,
    B: Fn(BarEvent) + Clone + 'static,
    Z: Fn(BazEvent) + Clone + 'static,
{
    todo!()
}

[gbj]

There are a few different questions to ask yourself when you find yourself in this situation:

1. If it's not local state, does it need its own component? You can keep it in a larger parent component.
2. Do all these props need to be passed into one component, or can I break this out into several smaller components with fewer props?
3. Is it cleaner if I pass some of these with provide_context and receive them with use_context instead of via props?
4. Is it cleaner if I use a struct and a message enum to create a state machine as I would in Elm, and pass that as a signal?

Without a more concrete example it's a bit hard to see what the answer is in your case, but those are some of the possibilities.

[flosse]

Without a more concrete example it's a bit hard to see what the answer is in your case

you're right.
So here is a concrete example.
Let's just focus on event handling for now.
What would be a better solution for the menu button events ( on_login, on_logout, etc.)?

#[derive(Debug, Clone)]
pub enum LoginStatus {
    LoggedIn,
    LoggedOut,
}

#[component]
pub fn Navbar<I, O, u, S>(
    cx: Scope,
    menu_is_active: RwSignal<bool>,
    login_status: ReadSignal<LoginStatus>,     
    on_login: I,
    on_logout: O,
    on_profile: P,
    on_settings: S
) -> impl IntoView
where
    I: Fn() + Clone + 'static,
    O: Fn() + Clone + 'static,
    P: Fn() + Clone + 'static,
    S: Fn() + Clone + 'static,
{
    let toggle_menu = move || {
        menu_is_active.update(|state| *state = !*state);
    };
    let navbar_class = move || {
        if menu_is_active.get() {
            "navbar-menu is-active"
        } else {
            "navbar-menu"
        }
    };
    view! { cx,
       <nav
          class = "navbar"
          role = "navigation"
          aria_label = "main navigation"
       >
          <div class="navbar-brand">
              <a class = "navbar-item" on:click = move |_|toggle_menu() >
                  { crate::TITLE }
              </a>
              <BurgerMenu
                  active = menu_is_active.read_only()
                  on_click = toggle_menu
              />
          </div>
          <div class = navbar_class>
              <div class="navbar-start"></div>
              <div class="navbar-end">
                  <div class="navbar-item">
                      <div class="buttons"> { move ||
                          match login_status.get() {
                              LoginStatus::LoggedIn => {
                                  view! { cx,
                                      <Button label = "Log out" on_click = on_logout.clone() />
                                      <Button label = "Profile" on_click = on_profile.clone() />
                                      <Button label = "Settings" on_click = on_settings.clone() />
                                  }.into_view(cx)
                              }
                              LoginStatus::LoggedOut => {
                                  view! { cx,
                                      <Button label = "Log in" on_click = on_login.clone() />
                                  }.into_view(cx)
                              }
                          }}
                      </div>
                  </div>
              </div>
          </div>
       </nav>
    }
}

#[component]
fn BurgerMenu<F>(cx: Scope, active: ReadSignal<bool>, on_click: F) -> impl IntoView
where
    F: Fn() + 'static,
{
  // todo
}

#[component]
fn Button<F>(cx: Scope, label: &'static str, on_click: F) -> impl IntoView
where
    F: Fn() + 'static,
{
    view! { cx,
      <a class="button is-light" on:click = move |_| on_click()>
        { label }
      </a>
    }
}

[gbj]

Yeah so this is a great example of what's sometimes called "prop drilling": some outside component passes a handler into Navbar, which passes it into Button or BurgerMenu, which assigns it to . Basically the approaches I described above are the options: you can drill through with props as you're doing, or use context to "skip levels". ie Navbar is just passing callbacks through, so its parent could provide them via context instead, which Button and BurgerMenu can consume.

Another approach is to trust individual components to do their own work, and colocate the event listeners. In your example, is it really the case that only the parent of the Navbar knows how to handle the clicks? Or is it possible that eg BurgerMenu can manage its own state?

It's worth noting, since you mentioned TEA, that TEA is explicitly opposed to this kind of componentization. You could definitely implement a more-TEA-like pattern in one of two ways:

1. Define a state type, store it in a signal and pass it to all the children (via props or context), allowing them to update it via messages.
2. Rather than components, use a bunch of view functions (as in TEA) that are basically methods on the root.

[flosse]

Thanks for your fast reply!
I'll now play around with the different approaches and see what feels most coherent to me.