Best way to access context from ContextProviders

[maurerdietmar]

It is quite ease to access a context from function components, i.e:

#[function_component]
fn TestPage1() -> Html {
   let page_controller: Option<PageController> = use_context();
   ...

But it is quite clumsy inside a Component impl.

fn view(&self, ctx: &Context<Self>) -> Html {
    let page_controller =  ctx.link().context::<PageController>(Callback::from(|_| {})).map(|(c, _)| c);
    ....

Is there an easier way to get the context?

[futursolo]

The current approach is by design. If you need to use contexts with struct components, you need to define a callback and hold the context handle. Without subscribing to a context, the component will not be notified for any updates. This results in inconsistency in your application. The current approach forces struct component users to define a callback so context updates can be sent to struct components.

If you want less boilerplate, you should consider using function components.
Hooks provides easier access and allows the hook to subscribe to the context on behalf of the user without having to manually handle any details, which is not possible with struct components.

[maurerdietmar]

If you want less boilerplate, you should consider using function components.

I clearly prefer struct Components for most things, so why can't we provide convenient helpers for them?
I was thinking about something like this (not tested):

use std::rc::Rc;
use std::cell::RefCell;

use yew::prelude::*;

use yew::{ContextHandle, BaseComponent};
use yew::html::{Scope, IntoEventCallback};

struct ContextObserverState<T: Clone + PartialEq + 'static> {
    _handle: Option<ContextHandle<T>>,
    value: Option<T>,
    on_change: Option<Callback<()>>,
}

pub struct ContextObserver<T: Clone + PartialEq + 'static> {
    state: Rc<RefCell<ContextObserverState<T>>>,
}

impl<T: Clone + PartialEq + 'static> ContextObserver<T> {

    pub fn new<COMP: BaseComponent, >(scope: Scope<COMP>) -> Self {

        let state = Rc::new(RefCell::new(ContextObserverState  {
            _handle: None,
            value: None,
            on_change: None,
        }));

        let (value, handle) = scope.context(Callback::from({
            let state = state.clone();
            move |new_value: T| {
                let on_change = {
                    let mut state = state.borrow_mut();
                    state.value = Some(new_value);
                    state.on_change.clone()
                };
                if let Some(on_change) = &on_change {
                    on_change.emit(());
                }
            }
        })).unwrap();

        *state.borrow_mut() = ContextObserverState {
            value: Some(value),
            _handle: Some(handle),
            on_change: None,
        };

        Self { state }
    }

    pub fn on_change(self, callback: impl IntoEventCallback<()>) -> Self {
        self.state.borrow_mut().on_change =  callback.into_event_callback();
        self
    }

    pub fn get(&self) -> Option<T> {
        self.state.borrow().value.clone()
    }
}

This is basically the functionality of use_context, adopted for struct components.
Or is this a bad idea? If so, why?

It should be even possible to use above ContextObserver to implement the use_context() hook ...

[futursolo]

I am not too sure how do you use this with struct components?

Currently, you always need to subscribe to changes with contexts, so struct components can receive context updates.

You need to wrap the updated context value into a message variant and process it in update lifecycle event.
So changes will be reflected on context subscribers. The callback should never be empty.

It should be used like the following:

        let (message, context_listener) = ctx
            .link()
            .context(ctx.link().callback(Msg::MessageContextUpdated))
            .expect("No Message Context Provided");

You can find the full example below: https://github.com/yewstack/yew/blob/master/examples/contexts/src/struct_component_subscriber.rs#L19

[maurerdietmar]

Code would look quite similar, but you only need to store the ContextObserver in your state (which stores both value and handle).

...

pub enum Msg {
    ContextUpdated,
}

pub struct StructComponentSubscriber {
    message_context: ContextObserver<MessageContext>,
}

impl Component for StructComponentSubscriber {
    type Message = Msg;
    type Properties = ();

    fn create(ctx: &Context<Self>) -> Self {
        let message_context = ContextObserver::new(ctx.link())
            .on_change(ctx.link().callback(|_| Msg::ContextUpdated));

        Self {
            message_context,
        }
    }

    fn update(&mut self, _ctx: &Context<Self>, msg: Self::Message) -> bool {
        match msg {
            Msg::ContextUpdated => { true } // just redraw
        }
    }

    fn view(&self, _ctx: &Context<Self>) -> Html {
        let message = match self.message_context.get() {
            Some(message_context) => message_context.inner.to_string(),
            None => String::from("No message context provided"),
        };
        html! {
            <h1>{ message }</h1>
        }
    }
}

[futursolo]

I have edited your comment so it will have syntax highlight.

I think this design doesn't provide enough benefit over the current one. They are very similar in terms of how they are used and this proposal uses interior mutability.
The current one encourages a different message variant to be defined for each context, this can be used to create custom logic around it. Sometimes you don't need to re-render, but to set a different event listener, etc.

In addition, the original design updates the context in a component lifecycle.
Component lifecycle events are not always executed immediately but governed by a scheduler.
This allows the component to also make any other changes that is needed for a component.

On the other hand, interior mutability is acknowledge immediately. This makes other functions (such as an event listener) that hold an Observer to be able to access values that otherwise might be not possible (e.g.: they should be unregistered by the context value update).

[maurerdietmar]

ok

[WorldSEnder]

As noted by other answers, you should connect to the context in your create method, not look it upt all the time in view. I suppose the question makes sense if we could provide a way to avoid having to implement a message and could instead decide whether to re-render directly in the callback passed to the context creation. Note that this would not have access to the component state with the current implementation, but we know which component requested access to the context, so we could internally do the scheduling for a re-render without having to pass messages. Image a ContextHolder<T> struct, similar but not the same as the current ContextHandle:

pub struct StructComponentSubscriber {
    message_context: ContextHolder<MessageContext>,
}

impl Component for StructComponentSubscriber {
    type Properties = ();

    fn create(ctx: &Context<Self>) -> Self {
        // We can internally hold the found Scope<ContextProvider<MessageContext>> and deref/clone
        // the context value on demand in view (no other component should have a MutRef to that provider's state there)
        // We know which component to re-render from the ctx
        let message_context = ctx.with_context::<MessageContext>(|new_ctx| {
             let should_rerender = todo!();
             should_rerender 
        });

        Self {
            message_context,
        }
    }

    fn view(&self, _ctx: &Context<Self>) -> Html {
        let message = match self.message_context.get() {
            Some(message_context) => message_context.inner.to_string(),
            None => String::from("No message context provided"),
        };
        html! {
            <h1>{ message }</h1>
        }
    }
}

[maurerdietmar]

As noted by other answers, you should connect to the context in your create method, not look it upt all the time in view.

Sorry, but this is exactly what I am doing (connect to the context in the create method).

Of cause, a way to avoid sending a message for re-render can be convenient. On the other side you sometimes need the
message if you want to alter state.

Anyways, the code I posted I a slightly modified version of what we have in the "use_context()" hook. So it would be possible to use the same code in the hook and in struct components.