Add documentation on how to create a Context Producer in a struct Component

[SirVer]

This is about:

• A typo
• Innaccurate/misleading documentation (e.g. technically incorrect advice)
• Undocumented code
• Outdated documentation
• Other

Problem

Yew 0.19 does not contain examples on how to deal with shared Context and the documentation is very sparse. Yew mainline contains examples to produce context in a function_component and how to subscribe to one in a function and a struct component - and again, the documentation remains sparse.

However, there is no mention or example on how to create a Context producer in a struct component and my experiments led nowhere.

I tried asking about this on Discord, but this is not a great way of getting help - questions are buried there never to be found again.

Questionaire (Optional)

• I'd like to write this documentation
• I'd like to write this documentation but I'm not sure what's needed
• I don't have time to add this right now, but maybe later

As mentioned, I am not qualified to write this documentation, since I cannot figure it out.

[WorldSEnder]

Yew mainline contains examples to produce context in a function_component

Note that example produces messages, not contexts. The Producer component linked would still be considered a consumer of the context - a function component, using use_context. The counterpart is the context provider implemented in MessageProvider.

Choosing UseReducerHandle<Message> as the context type adds some convenience and is only immediately available to context providers implemented as function components. But any type can work fine here and struct components should be able to easily emulate the behaviour with Callbacks.

On the context consumer side, a struct component example is also given, though I concede, it could be more clearly documented. The docs for Scope::context(..) seems to be lacking in content.

[SirVer]

Actually, I did make it work now. The problem seemed to be having a Router Element in my HTML. If I leave this out, everything works as expected:

So this works:

        html! {
            <ContextProvider<Rc<BarChartData>> context={self.data.clone()}>
                <BrowserRouter>
                <Nav />
                <div class="columns">
                    <div class="column is-3" id="filtering">
                        <h3>{ "Filtering" }</h3>

                        <DatePicker {on_changed}/>

                    </div>
                    <div class="column">
                        <main>
                            <BarChart />
                        </main>
                    </div>
            </div>
                </BrowserRouter>
            </ContextProvider<Rc<BarChartData>>>
        }

while this does not:

        html! {
            <ContextProvider<Rc<BarChartData>> context={self.data.clone()}>
                <BrowserRouter>
                <Nav />
                <div class="columns">
                    <div class="column is-3" id="filtering">
                        <h3>{ "Filtering" }</h3>

                        <DatePicker {on_changed}/>

                    </div>
                    <div class="column">
                        <main>
                            <Switch<Route> render={Switch::render(switch)} />
                        </main>
                    </div>
            </div>
                </BrowserRouter>
            </ContextProvider<Rc<BarChartData>>>
        }


fn switch(routes: &Route) -> Html {
    html! { <BarChart /> }
}

The only difference is the change from the verbatim BarChart to an indirection with Switch.

So this might not be a documentation bug, but instead a real bug where Switch is blocking ContextProvider of working.

[SirVer]

@WorldSEnder should I file a new issue for the above bug report, namely that ContextProvider does not work across Switch?

[WorldSEnder]

@SirVer that would indeed by unexpected, a bug report with a reproducible example would be appreciated :)

[SirVer]

@WorldSEnder I tried to make my failure case smaller, but once it was very small the problem did not reproduce again. I rebuild back up to my original starting point and everything continued working. I am confused, since the diff is nill, expect that I ran cargo update once, which changed dependencies in Cargo.lock. I have no reproducible bug to report for now, sorry for the noise.