<For> inside of <Suspense> or <ErrorBoundary>

[smessmer]

Is your feature request related to a problem? Please describe.
Using a <For> component inside of a <Suspense> or <ErrorBoundary>, with the list being a Signal<Result<Vec<...>>> or Signal<Option<Vec<...>>> likely breaks its optimization.

Example

#[component]
fn MyComponent(cx: Scope, list: Signal<Option<Vec<DataItem>>>) -> impl IntoView {
  view!{cx,
    <Suspense fallback=move || view!{cx, <p>{"Loading..."}</p>}>
      {move || {
        list.map(|list| {
          view!{cx, 
            <For
               each = move || list.clone()
               key = move |item| item.key
               view = move |cx, item| view!{cx, <Item item=item />}
            />
          }
        })
      }}
    </Suspense>
  }
}

If I understand reactivity correctly, then the signal will trigger on every change to the list, which will cause the whole <For> component to be re-created, disabling its optimization of just re-rendering the changed items. The same problem exists for <Transition> and <ErrorBoundary>.

Describe the solution you'd like
I'm not sure what the right solution is. If there is already a best practise for this scenario, I'd like to hear it. One potential solution I thought about is to make the each prop of the <For> component take a Signal of Option<Vec> or Result<Vec> instead of just Vec. It could then itself render the Option or Result, and only render the list in the Some/Ok variants. Rendering None/Err should correctly trigger Suspense/ErrorBoundary.

[gbj]

Converting this to a discussion since, as you say, it's more of a question than a feature request.

Here's an example. Adding a log to the view function is useful as it will show you exactly when it rerenders. Using this simple version of your example, I demonstrated to myself that each row is only rendered once.

#[server(SomeData, "/api")]
pub async fn some_data(len: usize) -> Result<Vec<usize>, ServerFnError> {
    Ok((0..len).collect())
}

#[component]
pub fn App(cx: Scope) -> impl IntoView {
    let (count, set_count) = create_signal(cx, 3);
    let data = create_resource(cx, count, some_data);
    view! { cx,
        <button on:click=move |_| set_count.update(|n| *n += 1)>"+1"</button>
        <MyComponent data/>
    }
}

#[component]
fn MyComponent(
    cx: Scope,
    data: Resource<usize, Result<Vec<usize>, ServerFnError>>,
) -> impl IntoView {
    let list = Signal::derive(cx, move || data.read(cx).and_then(|n| n.ok()));
    view! {cx,
      <Suspense fallback=move || view!{cx, <p>{"Loading..."}</p>}>
        {move || {
            view!{cx,
              <For
                 each = move || list().unwrap_or_default()
                 key = move |item| *item
                 view = move |cx, item| {
                    log!("rendering {item}");
                    view!{cx, <p>{item}</p> }
                }
              />
          }
        }}
      </Suspense>
    }
}

[gbj]

That case is even simpler, unless I'm misunderstanding you. The solution is the same: do the reactive read inside each.

let (data, set_data) = create_signal(cx, None::<Vec<usize>>);
view! { cx,
    <button on:click=move |_| {
        set_data.update(|items| {
            match items {
                None => *items = Some(Vec::new()),
                Some(items) => items.push(items.len())
            }
        });
    }>"+1"</button>
    <For
        each = move || data().unwrap_or_default()
        key = move |item| *item
        view = move |cx, item| {
        log!("rendering {item}");
        view!{cx, <p>{item}</p> }
    }
    />
}

[gbj]

Maybe you were asking about the control-flow/fallback part of the question, though, in which case just use <Show>, which memoizes its condition for you:

    let (data, set_data) = create_signal(cx, None::<Vec<usize>>);
    view! { cx,
        <button on:click=move |_| {
            set_data.update(|items| {
                match items {
                    None => *items = Some(Vec::new()),
                    Some(items) => items.push(items.len())
                }
            });
        }>"+1"</button>
        <Show
            when=move || data.with(Option::is_some)
            fallback=|cx| view! { cx, <p>"Empty"</p> }
        >
            <For
                each = move || data().unwrap_or_default()
                key = move |item| *item
                view = move |cx, item| {
                log!("rendering {item}");
                view!{cx, <p>{item}</p> }
            }
            />
        </Show>
    }

[smessmer]

Oh amazing, <Show> does exactly what I needed here. Thank you :)

[smessmer]

Is there a similar trick for combining this with an <ErrorBoundary>? i.e. a way to use it without calling Result::map?

The best I could come up with is

let (data, set_data) = create_signal(cx, Ok(Some(vec![1,2,3,4])));

<ErrorBoundary
  fallback=move |_, err| view! { cx, <p>{"Error"}</p>}
>
  <Show
      // Show the fallback when it's not loaded yet and also show it when an error happens so we can render the error
      when=move || data().unwrap_or(None).is_some()
      fallback = move |cx| {
          match data() {
              Ok(None) =>
                  view!{cx,
                      <div class="flex justify-center">{"Loading..."}</div>
                  }.into_view(cx),
              // Since we get here when an error happens, we need to make sure we render
              // that error so that the ErrorBoundary picks it up.
              Err(err) => Err::<(), _>(err).into_view(cx),
              Ok(Some(_)) => panic!("We shouldn't have hit the fallback"),
          }
      }
  >
      <For ... />
  </Show>
</ErrorBoundary>

[gbj]

I don't know. I haven't thought about it in particular but a very simple way to get the error boundary to trigger correctly would be to just do something like

<ErrorBoundary fallback=/* */>
  // create some dummy `Fn() -> Result<(), Error>` to trigger the error boundary
  {move || data.with(|data| data.map(|_| ()))}
  // Show, For, etc. that don't rerender
</ErrorBoundary>