Access server-side inserted value from `additional_context` on the client #1353

sebadob · 2023-07-14T17:22:50Z

sebadob
Jul 14, 2023

I guess something like this already exists and I just cannot find it.

I am trying to set up server side translation for different languages.
I already created a custom leptos_routes_handler which allows me to get "in between" the very first GET for a route, extract headers and decide on a language for the user depending on an already set locale cookie or otherwise the Accept-Language header as a fallback. Then inserting translation structs for each route works perfectly on the server. I currently put them into the
additional_context like so

pub(crate) async fn leptos_routes_handler(
    app_state: AppState,
    State(options): State<LeptosOptions>,
    req: Request<Body>,
) -> Response {

// some logic stuff up here

    let app_fn = |cx| view! { cx, <App/> };

    let t = I18nIndex::translate(&lang);
    let handler = render_app_to_stream_with_context(
        options.clone(),
        move |cx| {
            provide_context(cx, t.clone());
        },
        app_fn,
    );
    let (mut parts, body) = handler(req).await.into_response().into_parts()

// ... and then add some more custom headers an stuff...

I can then extract this value inside the <App /> component from the context perfectly fine with

// `.unwrap_or_else(|| I18nIndex::default())` to not panic during initial leptos route generation in main
let t = use_context::<I18nIndex>(cx).unwrap_or_else(|| I18nIndex::default());

My only question now is, if I can somehow access this same pre-rendered context on the client later on and if so, how.
Or do I have to use a server fn for this and if yes, how can I make sure that this data is available on the very first render to have a good SSO, or since server fn's are async by default, will it only be available later anyway?

My other idea was to just do it like now and on the client do another fetch for the same resource to initialize the context.
I already inserted it with a preload link into the meta tags which makes it avilable immediately without any flicker. But this is quite a complex setup and my hope is, that I somehow can access the server context (maybe through the meta context?).

edit:

Usually, I would just use a server fn right away, but especially the i18n is a bit tricky so have it available on the very first render for SSO.

Answered by sebadob

Jul 16, 2023

If someone else might have a similar problem, I finally have a clean and nice setup for this problem.
I got into some trouble when it should work with routing too, but here is how I got it working:

I have a server_fn that simply returns a struct with translations for each route and language
I changed the routes in the leptos router in a way, that they all point to a common component with just different indexes. Only the <nav> needs some special treatment here to make the client side routing flicker free and nice and pretty:

<Router fallback=|cx| {
    let mut outside_errors = Errors::default();
    outside_errors.insert_with_default_key(AppError::NotFound);
   view! { cx, <ErrorTemplate o…

View full answer

sebadob · 2023-07-14T17:30:15Z

sebadob
Jul 14, 2023
Author

I just found a part of the answer for the server fn question in the examples:

The server fn will begin loading on the server and resolve on the client, which means it will not be available on the very first render.

5 replies

sebadob Jul 14, 2023
Author

I guess I get the idea, yes.

I will do some testing with this and play around with the create_resource. I tried this already together with the use_context, which then produced lifetime errors and then I needed to check the nonce PR first. :D

A blocking resource was another idea too, since it would not really block at all, because I can preload from the meta tags.

Thank you so far and I will report when I have success with this.

sebadob Jul 14, 2023
Author

Okay, I got it working.

How I did it now:

I still have my custom routes handler, which I need anyway for other things too.
This does extract the current language and provides the additional context just like before -> used for the very first rendering on the server.
In addition, I used a create_resource with a server_fn which then resolves on the client.

This will for the very first render use the additional context and populate all fields correctly translated and at the same time there is no flicker on the client after the server fn resolves. This is not correctly reactive, since I am not using a signal for the translation, but since this never changes anyway, it is no big deal at all:

let t_res = create_resource(
    cx,
    || (),
    move |_| async { get_i18n().await.expect("fetch i18n") },
);
let t = if is_server() {
    use_context::<I18nIndex>(cx).unwrap_or_else(|| I18nIndex::default())
} else {
    t_res.read(cx).unwrap()
};

There is now only one thing left to make it really pretty so the console does not yell at me, and that is:
How can I do something like a .read_untracked() on a ressource? I did not find something in the docs about it. Is it possible at all?

I would really like to get rid of the additional context workaround, but that lets the initial generate_route_list in main panic, because this is being executed before the API is even up and running, of course.

sebadob Jul 15, 2023
Author

I improved the endpoint and made it work with different routes by returning an enum. Additionally, I am re-populating the context on the client side now. This needs a bit more code on each new route:

let t_res = create_resource(
    cx,
   || (),
    move |_| async move { get_i18n(cx, "index".to_string()).await.expect("fetch i18n") },
);
let t = if is_server() {
    use_context::<I18nIndex>(cx).unwrap_or_else(|| I18nIndex::default())
} else {
    let val = match t_res.read(cx).unwrap() {
        I18n::I18nIndex(i) => i,
        _ => unreachable!("i18n route / type mismatch between t_res and t"),
    };
    provide_context(cx, val.clone());
    val
};

But this is easily stripped down to just 2 lines for a new routes in the future with

macro_rules! t_res {
    ($cx:expr, $route:expr) => {
        create_resource(
            $cx,
            || (),
            move |_| async move { get_i18n($cx, $route.to_string()).await.expect("fetch i18n") },
        )
    };
}

macro_rules! t {
    ($cx:expr, $handle:expr, $item:ident) => {
        if is_server() {
            use_context::<$item>($cx).unwrap_or_else(|| $item::default())
        } else {
            let v = match $handle.read($cx).unwrap() {
                i18n::i18n::I18n::$item(r) => r,
                _ => unreachable!("i18n route / type mismatch between t_res!() and t!()"),
            };
            provide_context($cx, v.clone());
            v
        }
    };
}

Which means on top of a new component, I can now just do the following, after adding the route for the translation in the enum on the server side:

let t_res = t_res!(cx, "index");
let t = t!(cx, t_res, I18nIndex);

This is working perfectly fine, without any errors, panics, blinking, ...

The only thing left is the problem from my post above.
The console complains during hydration about using the t_res.read(cx) in a place where it is untracked. This is no problem, because this value is initalized once and then never changes again, but I want to get rid of the error log.

@gbj do you have a suggestion for me how I can read this value untracked?

sebadob Jul 16, 2023
Author

If someone else might have a similar problem, I finally have a clean and nice setup for this problem.
I got into some trouble when it should work with routing too, but here is how I got it working:

I have a server_fn that simply returns a struct with translations for each route and language
I changed the routes in the leptos router in a way, that they all point to a common component with just different indexes. Only the <nav> needs some special treatment here to make the client side routing flicker free and nice and pretty:

<Router fallback=|cx| {
    let mut outside_errors = Errors::default();
    outside_errors.insert_with_default_key(AppError::NotFound);
   view! { cx, <ErrorTemplate outside_errors/> }.into_view(cx)
}>
    <nav>
        <WithI18n route="nav".to_string()/>
        <footer>
            <LangSelector/>
        </footer>
    </nav>

    <main>
        <Routes>
            <Route path="" view=|cx| view! { cx, <WithI18n route="/".to_string()/> }/>
            <Route path="/other" view=|cx| view! { cx, <WithI18n route="/other".to_string()/> }/>
        </Routes>
    </main>
</Router>

The new WithI18n looks like this:

#[component]
pub fn WithI18n(cx: Scope, route: String) -> impl IntoView {
    let rte = store_value(cx, route);

    let t_res = create_resource(
        cx,
        move || rte.get_value(),
        move |route| async move { get_i18n(cx, route).await.expect("fetch i18n") },
    );

    if is_server() {
        // the `.unwrap_or_else(` for the `nav` and `/` are necessary to make the very first
        // automatic routes generation for the leptos options not panic in the servers `main.rs`
        // because the server is not even running yet at that point, which means the additional
        // context does not exist at that time
        let i18n = match rte.get_value().as_str() {
            "nav" => {
                // nav needs a special treatment here to make everything work in SSR mode even
                // with javascript possibly disabled on the client
                // take a look at the `routes_handler.rs` in the `server` package
                I18n::I18nNav(use_context::<I18nNav>(cx).unwrap_or_else(|| I18nNav::default()))
            }
            "/" => use_context::<I18n>(cx).unwrap_or_else(|| I18n::I18nIndex(I18nIndex::default())),
            _ => use_context::<I18n>(cx).unwrap(),
        };
        t_res.set(i18n);
    }

    view! { cx,
        <Transition fallback=move || {
            view! { cx, None }
        }>
            {move || {
                t_res
                    .with(
                        cx,
                        |i18n| {
                            match i18n.clone() {
                                I18n::I18nNav(t) => view! { cx, <Nav t/> }.into_view(cx),
                                I18n::I18nIndex(t) => view! { cx, <Home t/> }.into_view(cx),
                                I18n::I18nOther(t) => view! { cx, <OtherMain t/> }.into_view(cx),
                            }
                        },
                    )
            }}
        </Transition>
    }
}

A component that needs the translations only needs to accept the t prop, which is a different translation struct for each route, like so:

#[component]
pub fn HomeMain(cx: Scope, t: I18nIndex) -> impl IntoView {
    view! { cx,
        <h1>{t.welcome}</h1>
        <LangSelector/>
    }
}

Finally, the custom routes handler for the leptos routes inject the translations into the additional_context with a special treatment for the nav component:

pub(crate) async fn leptos_routes_handler(
    _app_state: AppState,
    State(options): State<LeptosOptions>,
    req: Request<Body>,
) -> Response {
    let lang_head = Language::try_from(req.headers());
    let lang = lang_head.unwrap_or(Language::En);

    let i18n = match req.uri().path() {
        "/" => I18n::I18nIndex(I18nIndex::new(&lang)),
        "nav" => I18n::I18nNav(I18nNav::new(&lang)),
        "/other" => I18n::I18nOther(I18nOther::new(&lang)),
        _ => unreachable!("unreachable route in custom leptos routes handler"),
    };
    // the nav needs a bit of a special treatment to make it really work with SSR on the first render
    // the problem is, that the nav needs to exist outside of the router to make client side routing
    // "nice and pretty" and therefore cannot be wrapped in a nice way inside the same `<WithI18n>`
    // with each route
    // since it has its own "route" called 'nav', and it has its own wrap inside `<WithI18n>` to
    // make everything work nicely, we need to inject just the nav translation additionally on the
    // server and make a custom extraction in `WithI18n` when doing the very first render on the server
    let i18n_nav = I18nNav::new(&lang);

    let handler = render_app_to_stream_with_context(
        options.clone(),
        move |cx| {
            provide_context(cx, i18n.clone());
            provide_context(cx, i18n_nav.clone());
        },
        |cx| view! { cx, <App/> },
    );
    let (mut parts, body) = handler(req).await.into_response().into_parts();

    let (k, v) = lang.set_cookie_str();
    parts.headers.insert(k, v);
    parts
        .headers
        .insert("content-type", HeaderValue::from_static("text/html"));
    Response::from_parts(parts, body)
}

Answer selected by sebadob

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Access server-side inserted value from `additional_context` on the client #1353

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 5 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Access server-side inserted value from additional_context on the client #1353

sebadob Jul 14, 2023

Replies: 1 comment · 5 replies

sebadob Jul 14, 2023 Author

sebadob Jul 14, 2023 Author

sebadob Jul 14, 2023 Author

sebadob Jul 15, 2023 Author

sebadob Jul 16, 2023 Author

Access server-side inserted value from `additional_context` on the client #1353

sebadob
Jul 14, 2023

Replies: 1 comment 5 replies

sebadob
Jul 14, 2023
Author

sebadob Jul 14, 2023
Author

sebadob Jul 14, 2023
Author

sebadob Jul 15, 2023
Author

sebadob Jul 16, 2023
Author