Contexts

Usually, data is passed from a parent component to a child component via props. But passing props can become verbose and annoying if you have to pass them through many components in the middle, or if many components in your app need the same information. Context solve this problem by allowing a parent component to make data available to any component in the tree below it, no matter how deep, without having to pass it down with props.

The problem with props: "Prop Drilling"

Passing props is a great way to pass data directly from parent to a child. They become cumbersome to pass down through deeply nested component tree or when multiple components share the same data. A common solution to data sharing is lifting the data to a common ancestor and making the children take it as props. However, this can lead to cases where the prop has to go through multiple components in order to reach the component needs it. This situation is called "Prop Drilling".

Consider the following example which passes down the theme using props:

use yew::{html, Children, Component, Context, Html, Properties, function_component};

#[derive(Clone, PartialEq)]
pub struct Theme {
    foreground: String,
    background: String,
}

#[derive(PartialEq, Properties)]
pub struct NavbarProps {
    theme: Theme,
}

#[function_component]
fn Navbar(props: &NavbarProps) -> Html {
    html! {
        <div>
            <Title theme={props.theme.clone()}>
                { "App title" }
            </Title>
            <NavButton theme={props.theme.clone()}>
                { "Somewhere" }
            </NavButton>
        </div>
    }
}

#[derive(PartialEq, Properties)]
pub struct ThemeProps {
    theme: Theme,
    children: Children,
}

#[function_component]
fn Title(_props: &ThemeProps) -> Html {
    html! {
        // impl
    }
}

#[function_component]
fn NavButton(_props: &ThemeProps) -> Html {
    html! {
        // impl
    }
}

/// App root
#[function_component]
fn App() -> Html {
    let theme = Theme {
        foreground: "yellow".to_owned(),
        background: "pink".to_owned(),
    };

    html! {
        <Navbar {theme} />
    }
}

We "drill" the theme prop through Navbar so that it can reach Title and NavButton. It would be nice if Title and NavButton, the components that need access to the theme, can just access the theme without having to pass it to them as prop. Contexts solve this problem by allowing a parent to pass data, theme in this case, to its children.

Using Contexts

Step 1: Providing the context

A context provider is required to consume the context. ContextProvider<T>, where T is the context struct is used as the provider. T must implement Clone and PartialEq. ContextProvider is the component whose children will have the context available to them. The children are re-rendered when the context changes. A struct is used to define what data is to be passed. The ContextProvider can be used as:

use std::rc::Rc;
use yew::prelude::*;

#[derive(Clone, Debug, PartialEq)]
struct Theme {
    foreground: String,
    background: String,
}

#[function_component]
fn NavButton() -> Html {
    let theme = use_context::<Rc<Theme>>().expect("Context not found");

    html! {
        // use theme
    }
}

#[function_component]
fn App() -> Html {
    let theme = use_memo(|_| Theme {
        foreground: "yellow".to_owned(),
        background: "pink".to_owned(),
    }, ());

    html! {
        <ContextProvider<Rc<Theme>> context={theme}>
            <NavButton />
        </ContextProvider<Rc<Theme>>>
    }
}

Step 2: Consuming context

Function components

use_context hook is used to consume contexts in function components. See docs for use_context to learn more.

Struct components

We have 2 options to consume contexts in struct components:

• Higher Order Components: A higher order function component will consume the context and pass the data to the struct component which requires it.
• Consume context directly in struct component. See example of struct component as a consumer

Use cases

Generally, if some data is needed by distant components in different parts of the tree, it's likely that context will help you. Here's some examples of such cases:

• Theming: You can put a context at the top of the app that holds your app theme and use it to adjust the visual appearance, as shown in the above example.
• Current user account: In many cases, components need to know the current logged-in user. You can use a context to provide the current user object to the components.

Considerations to make before using contexts

Contexts are very easy to use. That makes them very easy to misuse/overuse. Just because you can use a context to share props to components multiple levels deep, doesn't mean that you should.

For example, you may be able to extract a component and pass that component as a child to another component. For example, you may have a Layout component which takes articles as prop and passes it down to ArticleList component. You should refactor the Layout component to take children as props and display <Layout> <ArticleList {articles} /> </Layout>.

Mutating context value a child

Because of Rust's ownership rules, a context cannot have a method that takes &mut self that can be called by children. In order to mutate a context's value, we must combine it with a reducer. This is done by using the use_reducer hook.

The contexts example demonstrates mutable contexts with the help of contexts

Further reading

• The contexts example