Why is Send required for Resource on the frontend?

[sgoll]

First of all, I am pretty new to leptos, but not to Rust in general. In my experiments, I stumbled upon the same problem laid out in #3676 and I would like to understand the rationale behind relying on SendWrapper with its runtime checks on the client-side.

Am I right that LocalResource does not require Send-bounds because WASM is single-threaded, so all execution happens on the same thread—there are no other threads to send futures to? Also, LocalResource is evaluated only on the client-side, so server-side rendering (which would potentially be multi-threaded) is never invoking that future?

On the other hand, Resource might be evaluated on the server-side (initial render) or on the client-side (reactive application). Therefore, the future passed to it must be Send. But why on both sides? Wouldn't it be sufficient to require Send only on the server-side?

Right now, the future passed to Resource needs to be Send unconditionally, i.e. when compiling the server application (ssr) as well as the client application (csr/hydrate). This leads to stumbling blocks as shown in #3676 where isomorphic code such as using reqwest is not accepted with an error message that is rather difficult to pinpoint exactly.

Would it be worthwhile to go the same way as reqwest did and have the future not require Send for the WASM build? There is precedent for this in other crates than reqwest, for instance cynic in obmarg/cynic#597, for exactly the same reason.

[gbj]

My first and best answer to questions like this is always a suggestion: Try forking the repo, removing the bound, and then following the chain of errors all the way down to see what happens. I don't say this in a condescending way, but in a very practical way: It's very likely that in the end, the compiler will show the interrelationship of the various trait bounds here in a much more helpful way than I or anyone else can do just by trying to describe it from the top.

Am I right that LocalResource does not require Send-bounds because WASM is single-threaded, so all execution happens on the same thread? ... Also, LocalResource is evaluated only on the client-side, so server-side rendering (which would potentially be multi-threaded) is never invoking that future?

Basically yes.

On the other hand, Resource might be evaluated on the server-side (initial render) or on the client-side (reactive application).

Also yes.

But why on both sides? Wouldn't it be sufficient to require Send only on the server-side?

This is, in theory, possibly possible by creating a separate trait like PlatformSpecificSendSync where is implemented for all T on wasm32-unknown-unknown-without-atomics-support and T: Send + Sync on other targets. It has the potential to introduce quite a bit of conditional-compilation complexity throughout the codebase, although maybe it could be contained somewhat by doing it via another trait like this.

Would it be worthwhile to go the same way as reqwest did and have the future not require Send for the WASM build?

In my opinion, there is a pretty fundamental problem with the approach taken by reqwest here (target- or feature-based conditional compilation changing trait bounds and/or trait implementations) and it's that it really wrecks documentation and discoverability. For example, reqwest's docs tell me that Request is Send; so why do I get errors that say that Request is !Send because *mut u8 is !Send if I compile it for wasm32-unknown-unknown? Well, because on that target it's using a completely different mechanism, of course, one ultimately based on JsValue—but it allows the auto traits to percolate as they ordinarily would, rather than maintaining the same, documented trait impls regardless of target.

Arguably, this is only a problem because it applies to trait implementations (i.e., the type doesn't implement the traits it says it does, on some targets, in an undocumented and confusing way) rather than trait bounds: if something says it requires T: Send in the docs but on wasm32 I can pass it an Rc<()> that's less bad because it's more permissive, I guess.

I don't have particularly dogmatic beliefs about this; at present it's the least-messy in a series of messy compromises the framework has taken. I am open to better alternatives (in a future 0.9?) that cut through the Gordian knot here. Target-based compilation would certainly be one possibility, if it seems possible to do.

Any interest in exploring a PR that plays with that approach? I'm happy to gives pointers, but they'd mostly be "try switching out the bounds with a PlatformSendSync and see what errors out."