Hydration mismatch with nested closures in <Transition> when resources resolve at different times

[adrianncovaci]

I'm experiencing intermittent hydration errors when using with multiple resources that have different resolution times. The issue occurs when the Transition's outer closure only tracks one resource, while a nested closure accesses another resource that resolves later.

• Leptos version: 0.8
• Reproduction

The <Transition> only tracks fast_resource in its outer closure, while slow_resource is accessed in a nested move || closure:

  <Transition fallback=move || view! { <p>"Loading..."</p> }>
      {move || {
          match fast_resource.get() {
              Some(Ok(can_show)) => {
                  view! {
                      <div>
                          // Nested closure accessing slow_resource
                          {move || {
                              match slow_resource.get() {
                                  None => view! { <p>"Still loading..."</p> },
                                  Some(Ok(files)) => view! { <ul>...</ul> },
                                  // ...
                              }
                          }}
                      </div>
                  }
              }
              None => view! { <div></div> }
          }
      }}
  </Transition>

How to Reproduce

1. Clone the reproduction repository
2. Run cargo leptos watch
3. Reload the page multiple times in the browser
4. Check browser console for hydration mismatch errors

The race condition doesn't always trigger - you may need to reload several times.

Expected Behavior

I would expect one of the following:

1. The Transition should automatically track all resources accessed in nested closures, OR
2. A clear compile-time or runtime warning when resources are accessed in nested closures within a Transition

The workaround: access both resources in the outer closure:

  <Transition>
      {move || {
          match (fast_resource.get(), slow_resource.get()) {
              (Some(Ok(can_show)), Some(Ok(files))) => {
                  // Both loaded, render without nested closure
              }
              _ => view! { <div></div> }
          }
      }}
  </Transition>

Questions

1. Is this expected behavior? Should developers always avoid nested closures in Transitions when accessing resources?
2. Should this pattern produce a warning? It's quite subtle and easy to miss.
3. Is there a better way to handle multiple resources with different loading times while showing progressive loading states?

Thank you!

[gbj]

I don't see a race condition in the example provided -- it depends purely on whether the inner resource is already ready when the outer resource resolves, so in the example it is always broken. If I switch the timing of the two resources in the example it always works. I imagine the race condition comes in real code where you have two similarly-timed resources that finish in an arbitrary order any given time you call them.

Otherwise, your analysis of the situation is correct: Suspense/Transition

1. runs its children once,
2. tracks resource read during that initial run,
3. finishes rendering on the server when children tracked during Step 2 are all resolved.

This does mean that if you nest resource reads conditionally like this, it will not track the inner reads.

So:

Is this expected behavior? Should developers always avoid nested closures in Transitions when accessing resources?

Yes and yes.

Should this pattern produce a warning? It's quite subtle and easy to miss.

I'm sensing that you really mean "This pattern should produce a warning." In which case, a PR to add a warning or an issue adding this to the tracker would be welcome.

Is there a better way to handle multiple resources with different loading times while showing progressive loading states?

Yes.

I can see a few ways to handle the situation you'e encountered here:

Option 1: Nested Suspense

As far as I can tell your example works as intended if you simply use nested Suspense to show the two different loading states. Note that you can remove the None branches and simply .map() over the resource value, as the None branches will never be shown.

i.e., this

                                        <h4>"File List (from slow_resource):"</h4>
                                        <Transition fallback=|| view! { <p>"Still loading files..."</p> }>
                                          {move || {
                                            let slow_val = slow_resource.get();

Does exactly what you want, as far as I can tell.

And I think this is actually better than the one-Transition approach -- if you actually want to show two separate loading placeholders, and have the fast data appear while the slow data is still loading, you need two separate Suspense/Transition components, one for each chunk.

Option 2: Finer-grained resource reads

Note that if you do just want one Transition, which will stream all the content in at once, you can also do that with much more fine-grained resource reads. i.e., rather than wrapping a whole chunk of the UI in the resource read, you can read them where you use them, like any fine-grained signal. This also fixes the issue (because the resource reads are no longer nested) and also removes a large amount of boilerplate.

(You can catch the Err states with an ErrorBoundary or handle them explicitly in fine-grained reads, either way.)

            <Transition fallback=move || {
                view! { <p>"Loading..."</p> }
            }>
                <div style="border: 3px solid blue; padding: 20px; margin: 20px 0;">
                    <h3>"Content Area (fast_resource loaded)"</h3>
                    <p>"fast_resource value: " {move || fast_resource.and_then(|n| n.to_string())}</p>
                    <div style="border: 2px solid orange; padding: 15px; margin-top: 15px;">
                        <h4>"File List (from slow_resource):"</h4>
                        <Show
                            when=move || matches!(&*slow_resource.read(), Some(Ok(files)) if files.is_empty())
                            fallback=move || view! { <p>"No files found."</p> }
                        >
                            <ul>
                                {move || slow_resource.and_then(|files| {
                                    files
                                    .iter()
                                    .map(|file| {
                                        let file = file.clone();
                                        view! { <li>{file}</li> }
                                    })
                                    .collect_view()})}
                            </ul>
                        </Show>
                    </div>
                </div>
            </Transition>

[gbj]

I have made a PR (#4444) designed to address this category of Suspense issues. It does fix the issue in the example; I'd appreciate help testing it out on some larger examples as well.

[gbj]

(I spoke a bit too soon and will need to fix this one a bit before it's ready for testing!) probably fine now

[adrianncovaci]

Thank you very much for this! I tested a couple more pages and everything looks okay. I’m happy to help with additional stuff for this PR if you need anything else.