Skip to content

fix(deps): update rust crate leptos_router to v0.5.2 - #34

Closed
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/leptos_router-0.x
Closed

fix(deps): update rust crate leptos_router to v0.5.2#34
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/leptos_router-0.x

Conversation

@renovate

@renovate renovate Bot commented Jul 25, 2023 •
edited
Loading

Copy link
Copy Markdown
Contributor

Mend Renovate

This PR contains the following updates:

Package Type Update Change
leptos_router dependencies minor 0.4.5 -> 0.5.2
leptos_router dependencies minor 0.4 -> 0.5

Release Notes

leptos-rs/leptos (leptos_router)

v0.5.2

Compare Source

This has a bunch of bugfixes, small docs improvements, etc. but there are actually a bunch of cool new features, mostly from our growing body of contributors. See the full changelog below, but here are some highlights (apologies if I missed anything big)

Features
extractor() function with better API

The extract API is awkward due to closure. This adds an extractor function which is a little more ergonomic.

#[derive(Deserialize, Serialize, Debug, Clone)]
pub struct Search {
    q: String,
}

// Actix

#[server]
pub async fn query_extract() -> Result<Search, ServerFnError> {
    use actix_web::web::Query;
    use leptos_actix::extractor;

    let Query(query) = extractor().await?;
    Ok(query)
}

// Axum

#[server]
pub async fn data() -> Result<Search, ServerFnError> {
    use axum::extract::Query;
    use leptos_axum::extractor;
    
    let Query(query) = extractor().await?;
    Ok(query)
}
<Portal/>

Adds a portal component that lets you render some view mounted in a location other than where it appears in the view tree.

<Show when=show_overlay fallback=|| ()>
    <div>Show</div>
    <Portal mount=document().get_element_by_id("app").unwrap()>
        <div style="position: fixed; z-index: 10; width: 100vw; height: 100vh; top: 0; left: 0; background: rgba(0, 0, 0, 0.8); color: white;">
            <p>This is in the body element</p>
            <button id="btn-hide" on:click=move |_| set_show_overlay(false)>
                Close Overlay
            </button>
            <button id="btn-toggle" on:click=move |_| set_show_inside_overlay(!show_inside_overlay())>
                Toggle inner
            </button>

            <Show when=show_inside_overlay fallback=|| view! { "Hidden" }>
                Visible
            </Show>
        </div>
    </Portal>
</Show>
Server Function Named Arguments

Now that we've made all server function arguments optional, this adds in the ability to pass in one or more named arguments:

#[server(endpoint = "/path/to/my/endpoint")]
pub async fn my_server_action() -> Result<(), ServerFnError> {
    Ok(())
}

#[server(encoding = "GetJson")]
pub async fn my_server_action() -> Result<(), ServerFnError> {
    Ok(())
}
Directives

Adds support for directive functions, which can be used with use: in the view:

// This doesn't take an attribute value
fn my_directive(el: HtmlElement<AnyElement>) {
    // do sth
}

// This requires an attribute value
fn another_directive(el: HtmlElement<AnyElement>, params: i32) {
    // do sth
}

// ... in the view
view! {
  <div use:my_directive></div>
  <SomeComponent use:another_directive=5 />
}
slice!() macro

Makes it easier to define slices. Expands to the same output as create_slice:

#[derive(Default)]
pub struct State {
    count: i32,
    name: String,
}

let state = create_rw_signal(State::default());

let (count, set_count) = slice!(state.count);
What's Changed
New Contributors

Full Changelog: leptos-rs/leptos@v0.5.1...v0.5.2

v0.5.1

Compare Source

This is primarily a bugfix release, but it also includes a new feature: making the fallback prop on Show, Suspense, and Transition optional.

For 0.5 release notes in general, click here.

What's Changed

New Contributors

Full Changelog: leptos-rs/leptos@v0.5.0...v0.5.1

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.

Click here for more details. In order to provide signals that implement `Copy` are are `'static` and are therefore easy to use with closures and event listeners in 100% safe Rust, Leptos allocates memory for signals, memos, and effects in an arena. This raises the question: When is it safe to deallocate/dispose of these signals?

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.

This adds an experimental-islands feature that opts you into a rendering mode that's different from the traditional server-rendered/client-hydrated model described here, in which the entire page requested is rendered to HTML on the server for the first request, and then runs on the client to hydrate this server-rendered HTML, and subsequent navigations take place by rendering pages in the browser.

The experimental- in experimental-islands means “parts of this API may need to change, and I won’t guarantee that its APIs won’t break during 0.5,” but I have no reasons to believe there are significant issues, and I have no planned API changes at present.

With this islands feature on, components are only rendered on the server, by default. Navigations follow the traditional/multi-page-app (MPA) style of navigating by fetching a new HTML page from the server. The name "islands" comes from the concept of the "islands architecture," in which you opt into small “islands” of interactivity in an “ocean” of server-rendered, non-interactive HTML.

This allows reducing the WASM binary size by a lot (say ~80% for a typical demo app), making the time-to-interactive for a page load much faster. It also allows you to treat most components as “server components” and use server-only APIs, because those plain components will never need to be rendered in the browser.

I still need to write some guide-style docs for the book, but I tried to put a pretty good amount of information in the PR, which you should read if you’re interested in this topic or in trying out islands.

There’s significant additional exploration that will take place in this direction. Expect a longer treatment in an upcoming updated roadmap posted as a pinned issue.

Additional Reading
Static Site Generation

This release includes some preliminary work on building static site rendering directly into the framework, mostly as part of leptos_router and the server integrations. Static site generation is built off of two key components, a new <StaticRoute /> component and the leptos_router::build_static_routes function.

StaticRoute defines a new static route. In order to be a static route, all parent routes must be static in order to ensure that complete URLs can be built as static pages. A “static route” means that a page can be rendered as a complete HTML page that is then cached and served on subsequent requests, rather than dynamically rendered, significantly reducing the server’s workload per request.

StaticRoute takes a path and view (like any Route) and a static_params prop. This is a function that returns a Future, which is used to provide a map of all the possible values for each route param. These static params are generated on the server. This means you can do something like call a #[server] function or access a database or the server filesystem. For example, if you have a /post/:id path, you might query the database for a list of all blog posts and use that to generate a set of possible params.

StaticRoute can be given an optional mode: StaticMode::Upfront (the default) or StaticMode::Incremental. Upfront means that all given routes will be generated when you call build_static_routes, and a 404 will be returned for any other pages. Incremental means that all the options you give in static_params will be generated up front, and additional pages will be generated when first requested and then cached.

Where our routes are defined, we can include a StaticRoute:

view! {
	<Routes>
		<StaticRoute
			mode=StaticMode::Incremental
			path="/incr/:id"
			view=StaticIdView
			static_params=move || Box::pin(async move {
				let mut map = StaticParamsMap::default();
				map.insert("id".to_string(), vec![(1).to_string(), (2).to_string()]);
				map
			})
		/>
	</Routes>
}

In main.rs, we build the static routes for the site on server startup:

let (routes, static_data_map) = generate_route_list_with_ssg(App);
build_static_routes(&conf.leptos_options, App, &routes, &static_data_map)
	.await
	.unwrap();
More to Come

There is additional work needed here as far as providing examples, and building out the story for things like invalidation (when to rebuild a page) and build hooks (when to build additional pages).

Other New Features in 0.5
attr: on components, and spreading attributes

Makes it much easier to pass some set of attributes to be given to a component (with attr: passed into a #[prop(attrs)] prop), and then to spread them onto an element with {..attrs} syntax.

#[component]
pub fn App() -> impl IntoView {
    view! {
        <Input attr:value="hello" attr:label="foo" />
        <Input attr:type="number" attr:value="0" />
    }
}

#[component]
pub fn Input(
    #[prop(attrs)] attrs: Vec<(&'static str, Attribute)>,
) -> impl IntoView {
    view! {
        <input {..attrs} />
        <pre>{format!("{attrs2:#?}")}</pre>
    }
}
Generics on components in view

Newly added support for syntax that identifies a generic type for a component in the view

#[component]
pub fn GenericComponent<S>(#[prop(optional)] ty: PhantomData<S>) -> impl IntoView {
    std::any::type_name::<S>()
}

#[component]
pub fn App() -> impl IntoView {
    view! {
        <GenericComponent<String>/>
        <GenericComponent<usize>/>
        <GenericComponent<i32>/>
    }
}
Callback types

This release includes a Callback type that makes it much easier to pass optional callbacks as component props, which was previously not possible with generically-typed callbacks.

#[component]
fn MyComponent(
    #[prop(optional, into)] render_number: Option<Callback<(i32, i32), String>>,
) -> impl IntoView {
    render_number.map(|render_nummber| {
        view! {
            <div>
                // function call syntax works on nightly
                {render_number((42, 37))}
                // does the same thing
                {render_number.call((42, 37))}
            </div>
        }
    })
}

#[component]
pub fn App() -> impl IntoView {
    view! {
        <MyComponent render_number=|(x, y)| format!("x: {x} - y: {y}")/>
    }
}
with!() and update!() macros

Nested .with() calls are a pain. Now you can do

let (first, _) = create_signal("Bob".to_string());
let (middle, _) = create_signal("J.".to_string());
let (last, _) = create_signal("Smith".to_string());
let name = move || with!(|first, middle, last| format!("{first} {middle} {last}"));

instead of

let name = move || {
	first.with(|first| {
		middle.with(|middle| last.with(|last| format!("{first} {middle} {last}")))
	})
};
Rustier interfaces for signal types

This framework's origins as a Rust port of SolidJS mean we've inherited some functional-JS-isms. Combined with the need to pass cx everywhere prior to 0.5 this has tended to mean we've gone with create_ and so on rather than Rusty ::new(). This simply adds a few Rustier constructors like

let count = RwSignal::new(0);
let double_count = Memo::new(move |_| count() * 2);
Optional #[server] Arguments

All arguments to #[server]are now optional: change default prefix to /api and default to generating a PascalCase type name from the function name

// before

#[server(MyName, "/api")]
pub async fn my_name() /* ... */
// after

#[server]
pub async fn my_name /* ... */
JS Fetch API integration support

We have adapted the Axum integration to be usable when running inside JS-hosted WASM environments (Deno Deploy, Cloudflare Workers, etc.) This can be done by disabling default-features on axum and leptos_axum, using the axum-js-fetch library, and enabling the wasm feature on leptos_axum.

leptos_axum = { version = "0.5", default-features = false, optional = true }
axum = { version = "0.6", default-features = false, optional = true }
axum-js-fetch = { version = "0.2", optional = true }

##### ... 

[features]
default = ["csr"]
csr = ["leptos/csr", "leptos_meta/csr", "leptos_router/csr"]
hydrate = ["leptos/hydrate", "leptos_meta/hydrate", "leptos_router/hydrate"]
ssr = [
  "dep:axum",
  "dep:axum-js-fetch",
  "leptos_axum/wasm",

##### ...
]

There's a full Hackernews example in the repo that runs within Deno.

Feature Grab-Bag
  • Updated Resource APIs. Resources now follow the same API as other signals: .get() and .with() apply to the current value (which may be None). This means the old .with(), which was only called when the resource had resolved, is now .map(). There's also a new .and_then() method which can be called to deeply map over resources that return Result, like server functions. The goal of these methods is to reduce the amount of boilerplate mapping necessary with resources previously. Check out the Resource docs for more info.
  • create_effect now returns an Effect struct. This exists mostly so you can .dispose() it early if you need. (This may require adding some missing semicolons, as create_effect no longer returns ().)
  • create_effect’s first run is now scheduled on the next tick, using queueMicrotask. In other words, create_effect runs after your component returns a view, not immediately as the component runs. This removes most of the cases in which nesting request_animation_frame inside a create_effect had been necessary.
  • Support passing signals directly as attributes, classes, styles, and props on stable.
  • Many APIs that previously took impl Into<Cow<'static, str>> now take impl Into<Oco<'static, str>>. Oco (Owned Clones Once) is a new type designed to minimized the cost of cloning immutable string types, like the ones used in the View. Essentially this makes it cheaper to clone text nodes and attribute nodes within the renderer, without imposing an additional cost when you don't need to. This shouldn't require changes to your application in most cases of normal usage. (See #​1480 for additional discussion.)
Minor Breaking Changes
leptos_axum::generate_route_list()

This function is no longer async. This means removing a single .await from main.rs in any Leptos-Axum app, but brings the API of the Axum (and Viz) integrations into line with the Actix one, and unlocks the use of this function in some non-async settings where it was desired.

<For/> prop view renamed children

The name of the function that renders each row of data to a view is now children rather than view. This means that the view can now be included inline, without needing to break out of the markup into another closure and view! macro invocation.

In other words,

let (data, set_data) = create_signal(vec![0, 1, 2]);
view! {
    <For
        each=data
        key=|n| *n
        // stores the item in each row in a variable named `data`
        let:data
    >
        <p>{data}</p>
    </For>
}

is the same as

let (data, set_data) = create_signal(vec![0, 1, 2]);
view! {
   <For
       each=data
       key=|n| *n
       children=|data| view! { <p>{data}</p> }
   />
}

which replaces

let (data, set_data) = create_signal(vec![0, 1, 2]);
view! {
   <For
       each=data
       key=|n| *n
       view=|data| view! { <p>{data}</p> }
   />
}
use_navigate navigate function no longer returns a value

The navigate("path", options) call now uses request_animation_frame internally to delay a tick before navigating, which solves a few odd edge cases having to do with redirecting immediately and the timing of reactive system cleanups. This was a change that arose during 0.3 and 0.4 and is being made now to coincide with other breaking changes and a new version.

If you were relying on the Result<_, _> here and want access to it, let me know and we can bring back a version that has it. Otherwise, this shouldn't really require any changes to your app.

window_event_listener and friends now return a handle for removal

This one was just an API oversight originally, again taking advantage of the semver update. window_event_listener and its untyped version now return a WindowListenerHandle with a .remove() method that can be called explicitly to remove that event, for example in an on_cleanup.

#[component]
fn TypingPage() -> impl IntoView {
    let handle = window_event_listener(ev::keypress, |ev| {
        /* do something */
    });
    on_cleanup(move || handle.remove());
}
Other Breaking Changes
  • use_context no longer works inside event listeners, inside spawn_local, etc. Use use_context inside the body of a component and move the context data into those other closures. (See here for more details.)
  • bind: has been renamed let:, which makes more sense for variable binding. (This applies to components like Await and now For, which take arguments in their children.)
  • Transition’s set_pending prop now applies #[prop(into)], which means it can take any signal setter. If you were doing something already like set_pending=something.into() the compiler will now get confused; just remove that .into().
  • create_effect’s first run is now scheduled on the next tick, using queueMicrotask. In other words, create_effect runs after your component returns a view, not immediately as the component runs. (Listing this as both a feature and a breaking change, as it is a behavior change!)
  • The log!, warn!, and error! macros have been moved into a separate logging module to avoid naming conflicts with the log and tracing crates. You can import them as use leptos::logging::*; if desired.
  • Signal traits now take an associated Value type rather than a generic (see #​1578)
  • Changes to Resource APIs: the function formerly known as .with() is now .map(), and .read() is now .get() to match other signals.
What's Changed

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate
renovate Bot requested review from a team and dezren39 as code owners July 25, 2023 14:05
@renovate renovate Bot changed the title Update Rust crate leptos_router to 0.4.6 Update Rust crate leptos_router to 0.4.7 Aug 2, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from 9233d34 to e712c7c Compare August 2, 2023 22:39
@renovate renovate Bot changed the title Update Rust crate leptos_router to 0.4.7 Update Rust crate leptos_router to 0.4.8 Aug 3, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from e712c7c to 5cf245b Compare August 3, 2023 00:48
@renovate renovate Bot changed the title Update Rust crate leptos_router to 0.4.8 Update Rust crate leptos_router to 0.4.9 Aug 20, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from 5cf245b to de7ea7c Compare August 20, 2023 22:45
@renovate renovate Bot changed the title Update Rust crate leptos_router to 0.4.9 fix(deps): update rust crate leptos_router to 0.4.9 Aug 22, 2023
@renovate renovate Bot changed the title fix(deps): update rust crate leptos_router to 0.4.9 fix(deps): update rust crate leptos_router to 0.4.10 Aug 23, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from de7ea7c to a8549c1 Compare August 23, 2023 17:47
@renovate renovate Bot changed the title fix(deps): update rust crate leptos_router to 0.4.10 fix(deps): update rust crate leptos_router to v0.5.0 Sep 29, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from a8549c1 to eccb3fa Compare September 29, 2023 22:08
@renovate renovate Bot changed the title fix(deps): update rust crate leptos_router to v0.5.0 fix(deps): update rust crate leptos_router to v0.5.1 Oct 6, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from eccb3fa to c16c990 Compare October 6, 2023 15:48
@renovate renovate Bot changed the title fix(deps): update rust crate leptos_router to v0.5.1 fix(deps): update rust crate leptos_router to v0.5.2 Oct 25, 2023
@renovate
renovate Bot force-pushed the renovate/leptos_router-0.x branch from c16c990 to 5d25532 Compare October 25, 2023 01:48
@dezren39 dezren39 closed this Nov 7, 2023
This was referenced Oct 28, 2026
Closed
Closed
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@dezren39 dezren39 Awaiting requested review from dezren39 dezren39 is a code owner

Assignees

@dezren39 dezren39

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@dezren39