Clone bounds for signals/resources/memos are mostly not necessary about leptos HOT 4 CLOSED

So, since I alluded to it in the previous discussion: The only thing this would really affect is transitions.

The Clone requirement was originally because I had a use_transition() like the one in Solid or React, implemented in a way that required you to be able to clone the existing value. Basically, transitions "fork" reality so that the reactive system keeps moving along and updating "under transition" but not actually updating the UI until all the asynchronous work being done is complete. This does require T: Clone because you need to clone value to get transition_value.

This isn't necessary for something like our <Suspense/>, and in fact I've removed it because my implementation was buggy anyway. It enables some nicer UI for things like routing, but I'm sure that can be added manually.

I'm very open to removing the Clone requirement since it's not currently necessary and maybe reimplementing transitions in the future in a different way (or restricting which signals can have transitional values).

from leptos.

Interesting note on the transitions. Based only on your original comment, I had the impression that the Clones were mainly just legacy code that hadn't been removed yet but, if there's a reason they'll be needed in the future, it seems like you might as well keep them. I'd have to take a look at that old transitions implementation to make sure I actually understand what they do/how they do it to give any real feedback I'm afraid.

from leptos.

Re: transitions — If you're reading this (Dan or anyone else) and have no idea what I'm talking about, here's the classic Solid demo: without transitions and with transitions. Transitions are basically a way of "holding" an original state, while asynchronously transitioning to a new state, rather than flashing back to the <Suspense> fallback.

I've rewritten the reactive system since then, but here's how transitions would basically work in the current reactive system:

• There would be two additional field in Runtime: where now we have signal_values, there would be signal_t_values, and there would be a running_transition: Option<TransitionState> field to track the transition
• Calling start_transition() would set running_transition = Some(TransitionState::new())
• When we're in a transition, updating a signal would
  • clone the signal's value
  • apply the mutation to the clone
  • keep the original value around
• Effects called "under" the transitional state use the new transitional value; effects called "outside" the transition use the original value
  • this includes DOM rendering, which is built entirely on create_effect

In the Solid example, it "holds" the value of tab until the resource for the content has finished loading, then switches tabs. It's entirely possible to get the same UI effect (holding the previous state) as the Solid example manually; what Solid does (and what React does too, although implemented in a very different way) is a way to do this automatically, at the library level.

Given that, I think it makes sense to go ahead and remove the Clone requirements: at present it's not helping us actually do anything, and causes DX overhead in plenty of cases (see: camera example).

from leptos.

Closed in #37

from leptos.