Deserialization error with multiple Suspense about leptos HOT 5 OPEN

Thanks very much! I've been looking for a good reproduction of this particular issue for a couple months. I imagine it has been really annoying to debug, so apologies for that — hopefully this nice minimal reproduction will help me figure it out. Much appreciated.

from leptos.

After playing a bit with my application, I found this way to make it work using .with

This is great to hear!

That way other resources in the <Outlet/> are still created before it finishes loading. Does this seem good to you or would you have another suggestion?

This is totally ideal. The great thing about it is that it means that you remove a layer of waterfalls: if what's rendered in the <Outlet/> loads some data that doesn't depend on the guard, you begin loading that in parallel with the guard, rather than only after the guard is done.

Let's keep the issue open, because it's still a bug, but I'm glad you were able to refactor to avoid it.

from leptos.

I'm glad it helps then! ;) I quickly saw the resources' output were getting and I already had a minimal example similar to my application (that you made and showed me in another bug report actually '^^) so it was very simple to modify it a little bit and reproduce the issue. Thanks again for your help!

from leptos.

Ok so in this instance, it's relatively easy to fix the example, by changing this

move || guard_data.and_then(|_| view! { <Outlet/> })

to use .with() instead of .and_then()

move || guard_data.with(|_| view! { <Outlet/> })

The reason for this is that .map and .and_then on resources only run once the resource is resolved, but .with runs and takes an Option of the resource's current value. This means that the resources are actually created in a different order on the server and in the client, hence the mismatch in expected types.

On the server, you don't render Child until guard_data is loaded, so the resources are created in the order

1. guard_data
2. other_nested_data
3. (once guard data resolves) nested_data

On the client, by the time the page hydrates all resources have streamed in so the resources are created in the order

1. guard_data
2. nested_data
3. other_nested_data

Resources are assigned flat IDs, not scoped to anything else, which is why the types don't match: IDs 2 and 3 are reversed on client and server.

from leptos.

Thanks for the update :)

After playing a bit with my application, I found this way to make it work using .with:

resource.with(|result| match result {
    Some(Ok(_)) => {
        view! { <Outlet/> }.into_view()
    },
    Some(Err(e)) => {
        log::info!("Error: {}", e);
    },
    None => {
        view! { <Outlet/> }.into_view()
    },
})

That way other resources in the <Outlet/> are still created before it finishes loading. Does this seem good to you or would you have another suggestion?

In my case, it was also possible to dodge the error by moving some parts of the html (a DaisyUI drawer) before the <Routes> but using .with seems much safer.

from leptos.