Fine-grained reactivity when updating a Resource from a web socket

[lukexor]

The topic around Resources and web sockets has been a difficult implementation detail and I thought I had come to a working solution - but some recent update has started causing errors.

"Uncaught Error: closure invoked recursively or after being dropped"

I've been able to narrow this down to a specific use case of using thaw and their Popover component for hover tooltips inside of a component that is behind a Transition boundary, reading a Resource that was updated by a web socket.

I suspect thaw has some sort of closure state that goes stale when the component re-renders after the Resource has been updated - and what I'm hoping would solve it is to not re-render the entire component when the Resource is updated and instead have more fine-grained reactivity that is normally afforded to signals.

The reason for this specific architecture is to have a complete SSR page, that hydrates and continues to update with server data for displaying server-side metrics.

Below is an example using the websockets example from leptos.

I suspect this is just a bad pattern - but I have not been able to figure out how an alternative. My past attempts tried to pipe a Resource into a Signal and encountered other issues at the time.

The goal here would be to prevent the entire Popover component from re-rendering whenever the Resource is updated and instead just have the specific text-nodes update.

For this little demo - it's easily solved just be removing the extra mapping closure that gets the resource - but in my real application, of course, it's much more complicated with larger data structures and nested components with context and props that take Into<Signal<T>> and currently, afaik there is no impl for From<Resource<T>>

#[server(protocol = Websocket<JsonEncoding, JsonEncoding>)]
async fn tick_ws(
    _input: BoxedStream<u32, ServerFnError>,
) -> Result<BoxedStream<u32, ServerFnError>, ServerFnError> {
    use futures::{SinkExt, channel::mpsc};
    use std::time::Duration;

    let (mut tx, rx) = mpsc::channel(1);
    tokio::spawn(async move {
        let mut x = 1;
        loop {
            let _ = tx.send(Ok(x)).await;
            x += 1;
            tokio::time::sleep(Duration::from_secs(1)).await;
        }
    });

    Ok(rx.into())
}

#[component]
pub fn App() -> impl IntoView {
    let latest = Resource::new(|| (), async |_| "x: 0".to_string());

    if cfg!(feature = "hydrate") {
        spawn(async move {
            let (_, rx) = mpsc::channel(1);
            match tick_ws(rx.into()).await {
                Ok(mut stream) => loop {
                    while let Some(Ok(x)) = stream.next().await {
                        latest.set(Some(format!("x: {x}")));
                    }
                },
                Err(e) => leptos::logging::warn!("{e}"),
            }
        });
    }

    view! {
        <ConfigProvider>
            <Transition>
                {move || {
                    latest
                        .get()
                        .map(|latest| {
                            let latest_x = Signal::stored(latest);
                            view! {
                                <Popover>
                                    <PopoverTrigger slot>
                                        <div>"hover me"</div>
                                    </PopoverTrigger>
                                    {latest_x}
                                </Popover>
                            }
                        })
                }}
            </Transition>
        </ConfigProvider>
    }
}

[gbj]

Honestly I don't think I'd use a Resource in this situation, although I might be misunderstanding something. I think I would probably use a Store that gets updated when new data comes in from the websocket, and access its fields for fine-grained reactivity.

I'm not familiar enough with thaw to know what would cause the issue. If you can create a non-thaw reproduction, feel free to open an issue here and I'm happy to look at it.

[lukexor]

Thanks again. I'll test out some of this.

The main reason for wanting the SSR is avoiding the layout shifts and to have valid values while the wasm finishes loading. Earlier on this was more of a concern when the wasm bundle was larger and not split.

I'm not sure then if I understand how to read a resource in a fine-grained way? All of the examples I see usually involves either using Suspend in a closure or using .get() in a closure, which unless memoized, wouldn't the whole closure be re-run when the resource is updated and any views generated in the closure unmounted and re-rendered?

[lukexor]

Oh I guess one more note 😄 It is also very plausible to do this (apologies for errors, just typing in here so consider it pseudocode)

let latest = Resource::new(|| (), async |_| "x: 0".to_string());
move || Suspend::new(async move {
  let initial_value = latest.await;
  let value = Store::new(initial_value);
  
  if cfg!(feature = "hydrate") {
        spawn(async move {
            /* mutate the store whenever you get a new value */
        });
    }
    
  // create a UI that reads from the store fields
  // at this point, you only need to read from the store, as it has the initial value from the server
  // even during server rendering
})

This might be the best combo approach.

Oh! This is brilliant, I'll check this out

[lukexor]

Unfortunately, I can't quite figure out how to get the nested Suspend/Store to work with my actual app without some major re-architecting.

There's a few hitches - many of the structs used have internal prost structs (protobuf) which I have limited control over, so deriving Store/Patch on them isn't possible without creating copies with From impls to convert between them.

The second, is that these resources are used multiple times across routes and components, and it's currently structured that these are inserted into Context higher up in a ParentRoute such that leaves in the tree just call a use_status hook to get access to the Resource, then wrap it in a Suspense or Transition for accessing it.

I can't think of a good way to provide your suggested approach in a composable way that can be re-used - maybe some custom component that takes a children function providing the resource? not sure if that's a good approach or not.

[gbj]

Fair enough.

The Store idea was really just a way to get fine-grained access to the individual fields of a deeply-nested type.

You can do the same thing by putting it into a signal and deriving memos for the subfields, or by just accessing the resource (and, similarly, creating memos around the fields). Personally, I think the simplest solution (if the updates are coming primarily over a websocket) is to wait for it once in Suspense, stick the whole thing into a signal and then access the fields as memos. Rather than creating 30 different Suspense nodes. (This is really just a question of how many individual chunks you want to stream in from the server during SSR — but of course adding Suspense in many places, in order to support many individual chunks, increases the overall complexity of what you have to write significantly)

Of course it's possible the latest release just fixed the (presenting) issue of the dropped callback in any case and you can keep doing what you've been doing all along without rearchitecting 😄

[lukexor]

It did fix most of the issues yes! And I have been using sub-memos around fields for awhile now. So the original issue really had nothing to do with that or fine grained reactivity after all