build(deps): bump leptos_actix from 0.4.10 to 0.5.0

[dependabot]

Bumps leptos_actix from 0.4.10 to 0.5.0.

Release notes

Sourced from leptos_actix's releases.

v0.5.0

v0.5.0

Goodbye, Scope

This long-awaited release changes the nature of the reactive system by removing the entire concept of explicit Scope and the ubiquitous cx variable.

The primary impetus behind this change is that it increases the correctness of the behavior of the reactive system, and fixes several persistent issues.

From 0.0 to 0.4, Leptos allocated signals in a dedicated Scope, which was ubiquitous in APIs. This had several drawbacks

1. Ergonomics: It was annoying additional boilerplate to pass around.
2. Trait implementations: Needing an additional Scope argument on many functions prevented us from implementing many traits that could not take an additional argument on signals, like From, Serialize/Deserialize.
3. Correctness: Two characteristics made this system somewhat broken

• The Scope was stored in a variable that was passed around, meaning that the “wrong” scope could be passed into functions (most frequently Resource::read()). If, for example, a derived signal or memo read from a resource in the component body, and was called under a Suspense lower in the tree, the Scope used would be from the parent component, not the Suspense. This was just wrong, but involved wrapping the function in another closure to pass in the correct Scope.
• It was relatively easy to create situations, that could leak memory unless child Scopes were manually created and disposed, or in which on_cleanup was never called. (See #802 and #918 for more background.)

The solution to this problem was to do what I should have been doing a year ago, and merge the memory allocation function of Scope into the reactive graph itself, which already handles reactive unsubscriptions and cleanup. JavaScript doesn’t deal with memory management, but SolidJS handles its onCleanup through a concept of reactive ownership; disposing of memory for our signals is really just a case of cleanup on an effect or memo rerunning.

Essentially, rather than being owned by a Scope every signal, effect, or memo is now owned by its parent effect or memo. (If it’s in an untrack, there’s no reactive observer but the reactive owner remains.) Every time an effect or memo reruns, it disposes of everything “beneath” it in the tree. This makes sense: for a signal to be owned by an effect/memo, it must have been created during the previous run, and will be recreated as needed during the next run, so this is the perfect time to dispose of it.

It also has the fairly large benefit of removing the need to pass cx or Scope variables around at all, and allowing the implementation of a bunch of different traits on the various signal types.

Now that we don't need an extra Scope argument to construct them, many of the signal types now implement Serialize/Deserialize directly, as well as From<T>. This should make it significantly easier to do things like "reactively serialize a nested data structure in a create_effect" — this removed literally dozens of lines of serialization/deserialization logic and a custom DTO from the todomvc example. Serializing a signal simply serializes its value, in a reactive way; deserializing into a signal creates a new signal containing that deserialized value.

Migration is fairly easy. 95% of apps will migrate completely by making the following string replacements:

1. cx: Scope, => (empty string)
2. cx: Scope => (empty string)
3. cx, => (empty string)
4. (cx) => ()
5. |cx| => ||
6. Scope, => (empty string)
7. Scope => (empty string) as needed
8. You may have some |_, _| that become |_| or |_| that become ||, particularly for the fallback props on <Show/> and <ErrorBoundary/>.

Basically, there is no longer a Scope type, and anything that used to take it can simply be deleted.

For the 5%: if you were doing tricky things like storing a Scope somewhere in a struct or variable and then reusing it, you should be able to achieve the same result by storing Owner::current() somewhere and then later using it in with_owner(owner, move || { /* ... */ }). If you have issues with this kind of migration, please let me know by opening an issue or discussion thread and we can work through the migration.

Islands

This release contains an initial, but very functional, implementation of the “islands architecture” for Leptos.

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #49.