v0.7.0-preview2

[gbj]

v0.7.0-preview2

The -preview here is intended to convey: Here is a mostly-working but pre-alpha release of what I've been working on for the last six months or so. This work can be found in the leptos-0.7 branch. Enough work has been done that many (but not all) of the examples in the repo are functioning. This release is a fairly complete rewrite of the internals of the entire framework. You should expect both missing APIs and bugs.

Note the following:

• You probably cannot just drop 0.7.0-preview2 to the Cargo.toml of an existing app and expect it to work
• Imports have moved around a bit, to help improve discoverability, including moving from use leptos::*; to use leptos::prelude::*; and then using modules and reexports more sanely from the main crate
• I've created a 0.7.0-preview playground that includes the setup of a basic app with comments. You should be able to expand from there.
• There are lots of missing docs. These are easier to fill in going forward than to keep up to date during really active development.

Examples that Work

The following examples in the repo are known to work and can be useful to learn from

• counter
• counters
• error_boundary
• fetch
• todomvc
• parent_child
• router
• todo_app_sqlite_axum
• ssr_modes_axum

Notable Changes

• I'm trying to avoid using features to change behavior as much as possible; see examples for Cargo.toml setup
• use leptos::prelude::* instead of use leptos::*
• Reactive system is now Send/Sync. In general for values being stored in signals this means you need to use Arc on occasion instead of Rc, etc.
  • For browser-only types stored inside signals I've tended to use the send_wrapper crate. Better ergonomics here are an open question
• There are Arc equivalents to each signal type (ArcRwSignal, ArcMemo, etc.) which manage their lifecycle via reference counting rather than the reactive ownership graph. This can be used for things like iterating over nested signals (see counters example) and pushing signals "up" in the tree, rather than using the manual .dispose() and owner manipulation patterns
• Continuing to move names toward more typical Rust naming patterns (RwSignal::new(), signal() instead of create_signal() to match channel(), etc.)
• Suspense now uses actual async -- see examples
• The router uses a more statically-typed/compile-time route segment matching pattern. I have plans for a path!() macro to parse the old strings into this format but it's not implemented.
• Route matching is now "first match wins," rather than using a scoring algorithm. I think this should work similarly to server-side route matching, but is not exactly how the old system worked.

Known Missing APIs

• cargo-leptos hot reloading
• Actix integration (the playground uses Axum)
• on: on components
• spreading attributes onto components
• anything animated (AnimatedShow, AnimatedRoutes, AnimatedOutlet)
• Portals
• slots
• islands?
• ... will add more here

Steps before -alpha

• Migrate remaining examples
• Missing features (above)
• Update docs
• Update tests

What's Helpful?

Try things out, see what breaks, see what feels good. How can we improve the module imports? What are pain points? etc. Feel free to comment here or on Discord in the #preview channel,

---

This discussion was created from the release v0.7.0-preview2.

[dlight]

I've created a 0.7.0-preview playground that includes the setup of a basic app with comments. You should be able to expand from there.

This link is dead, was it supposed to link to a Github repository?

[gbj]

Should be fixed now, I'd just forgotten to make it public and of course the link worked when I checked it :-)

[CorvusPrudens]

I don't see it mentioned (and correct me if I'm wrong), but it looks like we're also missing MaybeSignals at the moment.

[jack-okeefe]

Thank you for all the work that you do!

[mscofield0]

What are the consequences of the Rc -> Arc change for end users of leptos?

[gbj]

Pros:

• Enables better server performance for Axum users
• Enables using the reactive system in native applications in a thread-safe way

Cons:

• values held in signals need to be Send + Sync, and/or we need a special wrapper or different signal type for signals that hold !Send values (like browser types). See Make reactive system Send/Sync #832 for further discussion.

It should not affect most code at all, as most types are already Send, except for types that ultimately hold some kind of JsValue.

[kaikalii]

Storing a View in a signal, cloning it, etc. are not viable approaches any more: store data in signals and rendering views, rather than storing views in signals.

I see this in the release page, but not in the version at the top of this discussion.
Will this still be the case?
I do this often. Is the intended alternative to just make an enum of the data sources, make it implement IntoView, and put it in the signal instead?

[gbj]

I see this in the release page, but not in the version at the top of this discussion.

I've updated the release notes as I've gone along and remembered more things, but not edited both documents -- GitHub just created the discussion from the original text.

I do this often. Is the intended alternative to just make an enum of the data sources, make it implement IntoView, and put it in the signal instead?

The intended use is to use signals to store data, and to use components and views to render the view. Alternately, there are other non-signal ways of sharing data (like channels) that can work well as a way of "sending" views.