Component Props

Just like you can pass arguments to a function or attributes to an element, you can pass props to a component that customize its behavior! The components we've seen so far didn't accept any props – so let's write some components that do.

#[derive(Props)]

Component props are a single struct annotated with #[derive(Props)]. For a component to accept props, the type of its argument must be Scope<YourPropsStruct>. Then, you can access the value of the props using cx.props.

There are 2 flavors of Props structs:

Owned props:
- Don't have an associated lifetime
- Implement PartialEq, allow for memoization (if the props don't change, Dioxus won't re-render the component)
Borrowed props:
- Borrow from a parent component
- Cannot be memoized due to lifetime constraints

Owned Props

Owned Props are very simple – they don't borrow anything. Example:

// Remember: Owned props must implement `PartialEq`!
#[derive(PartialEq, Props)]
struct LikesProps {
    score: i32,
}

fn Likes(cx: Scope<LikesProps>) -> Element {
    cx.render(rsx! {
        div {
            "This post has ",
            b { "{cx.props.score}" },
            " likes"
        }
    })
}

You can then pass prop values to the component the same way you would pass attributes to an element:

pub fn App(cx: Scope) -> Element {
    cx.render(rsx! {
        Likes {
            score: 42,
        },
    })
}

This post has 42 likes

Borrowed Props

Owned props work well if your props are easy to copy around – like a single number. But what if we need to pass a larger data type, like a String from an App Component to a TitleCard subcomponent? A naive solution might be to .clone() the String, creating a copy of it for the subcomponent – but this would be inefficient, especially for larger Strings.

Rust allows for something more efficient – borrowing the String as a &str – this is what Borrowed Props are for!

#[derive(Props)]
struct TitleCardProps<'a> {
    title: &'a str,
}

fn TitleCard<'a>(cx: Scope<'a, TitleCardProps<'a>>) -> Element {
    cx.render(rsx! {
        h1 { "{cx.props.title}" }
    })
}

We can then use the component like this:

pub fn App(cx: Scope) -> Element {
    let hello = "Hello Dioxus!";

    cx.render(rsx!(TitleCard { title: hello }))
}

Hello Dioxus!

Borrowed props can be very useful, but they do not allow for memorization so they will always rerun when the parent scope is rerendered. Because of this Borrowed Props should be reserved for components that are cheap to rerun or places where cloning data is an issue. Using Borrowed Props everywhere will result in large parts of your app rerunning every interaction.

Prop Options

The #[derive(Props)] macro has some features that let you customize the behavior of props.

Optional Props

You can create optional fields by using the Option<…> type for a field:

#[derive(Props)]
struct OptionalProps<'a> {
    title: &'a str,
    subtitle: Option<&'a str>,
}

fn Title<'a>(cx: Scope<'a, OptionalProps>) -> Element<'a> {
    cx.render(rsx!(h1{
        "{cx.props.title}: ",
        cx.props.subtitle.unwrap_or("No subtitle provided"),
    }))
}

Then, you can choose to either provide them or not:

Title {
title: "Some Title",
},
Title {
title: "Some Title",
subtitle: "Some Subtitle",
},
// Providing an Option explicitly won't compile though:
// Title {
//     title: "Some Title",
//     subtitle: None,
// },

Explicitly Required Options

If you want to explicitly require an Option, and not an optional prop, you can annotate it with #[props(!optional)]:

#[derive(Props)]
struct ExplicitOptionProps<'a> {
    title: &'a str,
    #[props(!optional)]
    subtitle: Option<&'a str>,
}

fn ExplicitOption<'a>(cx: Scope<'a, ExplicitOptionProps>) -> Element<'a> {
    cx.render(rsx!(h1 {
        "{cx.props.title}: ",
        cx.props.subtitle.unwrap_or("No subtitle provided"),
    }))
}

Then, you have to explicitly pass either Some("str") or None:

ExplicitOption {
title: "Some Title",
subtitle: None,
},
ExplicitOption {
title: "Some Title",
subtitle: Some("Some Title"),
},
// This won't compile:
// ExplicitOption {
//     title: "Some Title",
// },

Default Props

You can use #[props(default = 42)] to make a field optional and specify its default value:

#[derive(PartialEq, Props)]
struct DefaultProps {
    // default to 42 when not provided
    #[props(default = 42)]
    number: i64,
}

fn DefaultComponent(cx: Scope<DefaultProps>) -> Element {
    cx.render(rsx!(h1 { "{cx.props.number}" }))
}

Then, similarly to optional props, you don't have to provide it:

DefaultComponent {
number: 5,
},
DefaultComponent {},

Automatic Conversion with .into

It is common for Rust functions to accept impl Into<SomeType> rather than just SomeType to support a wider range of parameters. If you want similar functionality with props, you can use #[props(into)]. For example, you could add it on a String prop – and &str will also be automatically accepted, as it can be converted into String:

#[derive(PartialEq, Props)]
struct IntoProps {
    #[props(into)]
    string: String,
}

fn IntoComponent(cx: Scope<IntoProps>) -> Element {
    cx.render(rsx!(h1 { "{cx.props.string}" }))
}

Then, you can use it so:

IntoComponent {
string: "some &str",
},

The component macro

So far, every Component function we've seen had a corresponding ComponentProps struct to pass in props. This was quite verbose... Wouldn't it be nice to have props as simple function arguments? Then we wouldn't need to define a Props struct, and instead of typing cx.props.whatever, we could just use whatever directly!

component allows you to do just that. Instead of typing the "full" version:

#[derive(Props, PartialEq)]
struct TitleCardProps {
    title: String,
}

fn TitleCard(cx: Scope<TitleCardProps>) -> Element {
    cx.render(rsx!{
        h1 { "{cx.props.title}" }
    })
}

...you can define a function that accepts props as arguments. Then, just annotate it with #[component], and the macro will turn it into a regular Component for you:

#[component]
fn TitleCard(cx: Scope, title: String) -> Element {
    cx.render(rsx!{
        h1 { "{title}" }
    })
}

While the new Component is shorter and easier to read, this macro should not be used by library authors since you have less control over Prop documentation.

Component Children

In some cases, you may wish to create a component that acts as a container for some other content, without the component needing to know what that content is. To achieve this, create a prop of type Element:

#[derive(Props)]
struct ClickableProps<'a> {
    href: &'a str,
    body: Element<'a>,
}

fn Clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
    cx.render(rsx!(
        a {
            href: "{cx.props.href}",
            class: "fancy-button",
            &cx.props.body
        }
    ))
}

Then, when rendering the component, you can pass in the output of cx.render(rsx!(...)):

cx.render(rsx! {
    Clickable {
        href: "https://www.youtube.com/watch?v=C-M2hs3sXGo",
        body: cx.render(rsx!("How to " i {"not"} " be seen")),
    }
})

Note: Since Element<'a> is a borrowed prop, there will be no memoization.

Warning: While it may compile, do not include the same Element more than once in the RSX. The resulting behavior is unspecified.

The children field

Rather than passing the RSX through a regular prop, you may wish to accept children similarly to how elements can have children. The "magic" children prop lets you achieve this:

#[derive(Props)]
struct ClickableProps<'a> {
    href: &'a str,
    children: Element<'a>,
}

fn Clickable<'a>(cx: Scope<'a, ClickableProps<'a>>) -> Element {
    cx.render(rsx!(
        a {
            href: "{cx.props.href}",
            class: "fancy-button",
            &cx.props.children
        }
    ))
}

This makes using the component much simpler: simply put the RSX inside the {} brackets – and there is no need for a render call or another macro!

cx.render(rsx! {
    Clickable {
        href: "https://www.youtube.com/watch?v=C-M2hs3sXGo",
        "How to " i {"not"} " be seen"
    }
})

How to not be seen