How to handle pitfalls of global context during SSR time

[intendednull]

With the recent work on SSR support (#48), I've run into a problem with allowing access to global context during SSR time.

The global context is thread-local, meaning it is shared by everything in the same thread. In a web environment (strictly single-threaded), this effectively means app-wide shared state. However during SSR time, this isn't always true. In fact, using the global context during SSR time can be unsafe. For example if user details are saved in global context during SSR time of one session, they could accidentally leak into any other active session during that thread.

To avoid accidental leakage, I've proposed the use of a new dedicated context provider: YewduxRoot. This component is added to the root of the project, and provides a context that is contained to the actual app (instead of entire thread). Hooks automatically detect the root context, so little else needs to be changed (at least for functional components).

use yew::prelude::*;
use yewdux::prelude::*;

#[derive(Default, Clone, PartialEq, Eq, Store)]
struct State {
    count: u32,
}

#[function_component]
fn Counter() -> Html {
    let (state, dispatch) = use_store::<State>();
    let onclick = dispatch.reduce_mut_callback(|state| state.count += 1);
    html! {
        <>
        <p>{ state.count }</p>
        <button {onclick}>{"+1"}</button>
        </>
    }
}

#[function_component]
fn App() -> Html {
    html! {
        <YewduxRoot>
            <Counter />
        </YewduxRoot>
    }
}

However we cannot guarantee users will know (or remember) to do this, and accidentally using global context incorrectly could lead to headaches, or worse.

There are three options that I can think of:

1.) Allow access to the global context during SSR time. There are advantages to allowing its use, however we would need to rely completely on documentation to avoid dangerous pitfalls.

2.) Disallow access to the global context during SSR time by explicitly panicking. This will block global context usage on the server, while still allowing it in a web environment. It does introduce a runtime error that might be confusing to users, but removes the pitfall entirely.

3.) Remove the global context entirely. This will also make it impossible to fall into the pit, with the added bonus of sidestepping the annoying runtime error. However without a global context, it becomes less convenient to use struct components in non-ssr apps. Likely requiring the higher order components pattern to work.

[sjud]

My use case for SSR + global state: I pass in my AppProps with a context dependent state from my server.

I think at this high level of abstraction, you can put a warning on the library docs page. I don't think yewdux will be relied on in a way that users will ever not be reasonably expected to read the documentation. People still won't necessarily read the documentation, but if you are using a state management library in your web app I think it's reasonable to expect people to at least glance long enough at the front page of the documentation to see a big yellow warning. :)

I don't know if this is the best form but here is what I do now

#[derive(Clone, Debug, PartialEq, Properties, Default)]
pub struct AppProps {
    #[cfg(not(target_family = "wasm"))]
    pub(crate) inner: InnerAppProps,
}
#[cfg(not(target_family = "wasm"))]
#[derive(Clone, Debug, PartialEq, Properties, Default)]
pub struct InnerAppProps {
    pub auth: Option<InnerAuth>,
    pub url: AttrValue,
    pub queries: HashMap<String, String>,
    pub server_state: crate::state::ServerState,
}

#[function_component(AppComp)]
pub fn app(props: &AppProps) -> Html {
    #[cfg(not(target_family = "wasm"))]
    {
        let server_state = Dispatch::<SsrServerState>::new();

        server_state.reduce_mut(|state| state.server_state = props.inner.server_state.clone());
    }
 //then later
    let resp = Dispatch::<SsrServerState>::new().get()
            .server_state.graphql_schema.execute(req)
            .await
            .into_result()
            .map_err(|err|err_state_c.set(err));

[intendednull]

Thanks for your input! To be clear, blocking global context wouldn't prevent you from doing this. It would however make it a little less convenient to setup properly, since you would be passing around the app context manually when not using functional components

[sjud]

Ah of course! Makes sense. Then in that case it probably should be blocked. :)

[bwqr]

Hi there,

Just wanted to share my opinion. I find myself liking the approach of defining a root to define a context similar to yew's Context compared to a global context. And this should be the default behavior for the library itself. For this reason, I vote for Remove the global context entirely option. Additionally, I cannot find a compelling reason to use a global context.

As a question, I could not find the YewduxRoot component in the library. Is this still in development or cancelled?

Edit: Found it #48.

[intendednull]

Currently taking a hybrid approach. Global context will only be available when compiling wasm. App-local context is enforced for SSR.