Leptos store & SSR vs client side reactivity

[s1n7ax]

I watched Leptos October Meetup: Stores, 0.7 and more but wasn't live to ask questions.

This is bit of a long question but I guess background is important.

I have recently did a POC with React & MobX state manager with deeply nested object as store to see how it performs. I have two videos in readme to show the issue I was facing.

https://github.com/s1n7ax/poc-react-mobx-complex-form

MobX is a signal based, battle-tested library that makes state management simple and scalable by transparently applying functional reactive programming. The philosophy behind MobX is simple

In terms of behavior, it's similar to Leptos 0.7 store, meaning, it tracks exact path of properties that's used inside a observed closure (in this case it's a react functional component) and only updates the component if there is a change in that exact path. Reactivity works absolutely perfectly meaning it only updates the components that uses the exact path.

When I first load the page, I get the immediate view of all components thanks to SSR BUT it took hell of a long time for those components to be interactive for 500 components which shouldn't be a big deal in theory.

I asked this question on reddit to understand what the hell is going on.

https://www.reddit.com/r/reactjs/comments/1gh1sy3/time_to_be_intractable_is_high_with_mobx/

Conclusion is, on the browser, to make all those 500 components reactive, MobX has to proxy the deeply nested object which includes all 500 of the element data and then render them at least once on browser to detect all the dependencies, then only everything is reactive. HOWEVER, MUI elements takes a huge amount of time to render because they are somewhat heavy (confirmed by MUI contributor in the comments), so 500 takes around 5 seconds and all that is blocking so the entire page is frozen for 5 seconds.

Here, in the video you mentioned something about a separate hash map since there are no proxies in Rust.
https://youtu.be/yrG61ci7tz8?t=2375

So my question is, do you hydrate that hash map from server to client so on browser you don't even need a initial render to detect the dependencies of each property meaning everything is reactive in an instant if I did the same kind of test in Leptos with Leptos Store? I think this is a huge game changer for me at least if that's the case.

[gbj]

Hm yeah, bunch of separate questions here.

1. Is it cheaper to create 500 entries in the Store HashMap than it is to create 500 fields via a JavaScript proxy? Probably, I'd think? I do not have a good way to benchmark or test that.
2. Is it faster to hydrate 500 Leptos components than 500 React components? Yes, probably; the two frameworks work in very different ways.
3. Does the amount of time change when you remove the console.log logs from the top of each of your components? Logging is also blocking and logging that much in a relatively hot loop can actually create measurable drag (although maybe not up to 5s)

Do you mean that there are 500 items in the list of things going into the ComponentList, or do you mean 500 DOM elements? It looks like each of these components in the switch statement is doing a lot of work (creating multiple other closures, invoking other components, etc.)

And of course, as always, make sure your results are coming from release mode as opposed to dev/debug mode, especially for a heavy page like this.

[s1n7ax]

@gbj I guess that's not quite I wanted to know. My question is more like,

Next JS renders the components in the server, but it does not hydrate the MobX store (or rather mobx does not support it I assume). So, to provide the reactivity, it needs to re-render the entire page once again in the client. So, if the components are either heavy, or let's say blocked by hell of a lot of console.logs, entire page will freeze for some time until initial render is done.

What I wanted to know is, whether Leptos hydrates the Hash Map that tracks the dependencies along with the HTML so that Leptos does not require any initial render to track dependency hens it's intractable as soon as WASM is running.

I could be completely delusional about how Leptos works. I'm just guessing somehow Leptos knows how to reference each component to actual DOM element so it does not need any initial render on browser.

[gbj]

I'm just guessing somehow Leptos knows how to reference each component to actual DOM element so it does not need any initial render on browser.

This is the gap in understanding. Like any framework that hydrates, yes, Leptos will run your application code once on the server (to generate HTML) and then once on the client (to add interactivity to that HTML). That means that if you do something expensive in your logic, it happens in each of those places.

"Hydrate the HashMap" would mean something like "serialize the keys and values of the HashMap, send that as JSON from the server to the client, then deserialize it into a new HashMap on the client." In any framework and any programming language this would be much slower than simply creating the new HashMap on the client without the ser/des step.

So, if the components are either heavy, or let's say blocked by hell of a lot of console.logs, entire page will freeze for some time until initial render is done.

I just spun your application up locally. The performance problem is not the MobX Proxy and it is not MUI, and in fact it's not the console.logs. It is the fact that you are creating 39,850 HTML elements in order to load the page (open the page and run document.querySelectorAll("*").length in the console to see this number). You need to use a virtual list instead. Switching frameworks or programming languages will not help you here. Stick with React and just virtualize the list -- there are lots of great libraries to do this, I am sure.