Roadmap (0.4 and beyond)

[gbj]

(This supersedes the roadmap in #501.)

Roadmap

Goals for 0.4.0

• Axum extract function (feat: add Axum extract() function #1093)
• Improvements to <For/> algorithm (<For/> ignores the order of items #533, For algo v2 #1146)
• Remove need to explicitly call ::register() on server functions (Remove the register function from server_fn #613, feat: register server functions automatically #1154)
• Consider using anyhow in <ErrorBoundary/> and friends (feat: add an anyhow-like Result type for easier error handling #1228)
• Support generics in multiple positions in components (Rewrite inline generic bounds #949, Const generics don't work on components and slots #1023, Initial fix for #949 + #1023 #1109)
• Breaking: Reorganize features so that nightly is an opt-in feature and stable is default (change: rearrange features #1007, change: migrate to nightly and csr features rather than stable and default-features = false #1227)

Goals for 0.5.0

• Breaking Changing reactive ownership model to avoid manual use of Scope and cx everywhere (Fixing scope handling on dynamic children #802, change: shift from Scope-based ownership to reactive ownership #918)
• (?) Breaking: Use new bind: syntax for typed children on <For/> and possibly other control-flow components, when useful (feat: variable bindings on components and slots #1140)

Non-breaking improvements

• Reduce number of hydration keys and component comment markers (Omit hydration keys for static nodes #972, Don't render empty unnecessary component closing comments #903)

Goals for Future

• Exploring partial hydration/server components/islands architectures that would allow us to reduce the amount of WASM shipped to the client and increase the ergonomics of loading server-only async data
• Send/Sync reactive system to improve ergonomics (and possibly performance) of Axum integration (Make reactive system Send/Sync #832)

Ongoing work with no breaking changes

• Website.
• Completing the guide/book.
• Adding end-to-end testing for examples as part of our CI (CI: add Playwright or wasm-bindgen-test testing for examples and run them using cargo-make #210). There has been much work by @agilarity on improving CI on the examples, including testing.

[martinfrances107]

I have to say I really like this project, and this issue is well structured, I like the delineation of breaking changes.

I just want to introduce a sideways perspective -- "Reasons to walk away from 0.3"

So here is a consumer's story

When I follow the template step and produce a new project from leptos version "0.3" and check the project into a github repository employing dependabot

I get security warnings Ouroboros is Unsound

Here is my analysis or the situation

when I ask

cargo why ouroboros

I see "leptos_reative" is the only thing pulling in ouroboros

Also this issue was resolved a few says ago with this PR

Replace ouroboros with self_cell

I appreciate managing the pace of releases is not straight forward

To argue against my point -- Some consumers will be put off by the frequent publication of releases with breaking changes, seeing that incorrectly as sign of instability.

So I am just adding a single factor into a complex decision

At some point we must get off 0.3

---

output of cargo why

photo_indexer -> leptos -> leptos_dom -> leptos_reactive -> ouroboros
photo_indexer -> leptos -> leptos_reactive -> ouroboros
photo_indexer -> leptos -> leptos_server -> leptos_reactive -> ouroboros
photo_indexer -> leptos_meta -> leptos -> leptos_dom -> leptos_reactive -> ouroboros
photo_indexer -> leptos_meta -> leptos -> leptos_reactive -> ouroboros
photo_indexer -> leptos_meta -> leptos -> leptos_server -> leptos_reactive -> ouroboros
photo_indexer -> leptos_router -> leptos -> leptos_dom -> leptos_reactive -> ouroboros
photo_indexer -> leptos_router -> leptos -> leptos_reactive -> ouroboros
photo_indexer -> leptos_router -> leptos -> leptos_server -> leptos_reactive -> ouroboros

[gbj]

I have to say I really like this project, and this issue is well structured, I like the delineation of breaking changes.

Thanks! And thank you for all your contributions keeping things clean.

So here is a consumer's story

When I follow the template step and produce a new project from leptos version "0.3" and check the project into a github repository employing dependabot

I get security warnings Ouroboros is Unsound

...

Also this issue was resolved a few says ago with this PR

Replace ouroboros with self_cell

To me, the solution here seems pretty straightforward -- I am just going to create a branch that rewinds to the commit that released v0.3.0, apply the single commit that replaced ouroboros with self_cell, run the test suite against it, and release as v0.3.1. That way, anyone who is using main is safe (because the problem has been fixed on main) and also gets the various new features of the last month; and anyone on 0.3.0 can use 0.3.1 without pulling in any of the breaking changes.

I appreciate managing the pace of releases is not straight forward

To argue against my point -- Some consumers will be put off by the frequent publication of releases with breaking changes, seeing that incorrectly as sign of instability.

My perspective on this broader question is pretty straightforward: there are some breaking changes that are unforeseen, and some that are planned. For example, implementing extract for Axum ended up requiring changing some other, public-but-rarely-used functions, a breaking change. On the other hand, things like reorganizing features and changing reactive ownership are things I know are coming, but sometimes move slowly because I do all of this in my spare time.

I'm not bothered at all by the perception of instability due to version numbers; but I do think it's useful to group breaking changes together in releases so that people can sit down and migrate all at once.

Given the fairly rapid rate of releases (0.1 was only in late December/January, after all!) I'm pretty comfortable leaving some new features sitting on main for a while to avoid releasing 0.4, 0.5, and 0.6 in June, July, and August, and requiring a slow trickle of rewrites. Of course many users will simply track main and gradually rewrite anyway, and that's great!

For security things like the ouroboros situation I think an ad hoc extra patch release makes sense.

[nomorechokedboy]

• Adding end-to-end testing for examples as part of our CI (

I saw that some of the examples still doesn't have the end-to-end testing, can I write e2e test for them?

[gbj]

• Adding end-to-end testing for examples as part of our CI (

I saw that some of the examples still doesn't have the end-to-end testing, can I write e2e test for them?

That would be really, really great.

[agilarity]

• Adding end-to-end testing for examples as part of our CI (

I saw that some of the examples still doesn't have the end-to-end testing, can I write e2e test for them?

That would be really, really great.

I am adding e2e tests for the counters_stable example. The PR will include more cargo make tasks to support trunk and playwright. See PR #1235

[dezren39]

Exploring partial hydration/server components/islands architectures that would allow us to reduce the amount of WASM shipped to the client and increase the ergonomics of loading server-only async data

this would be very cool. +1 for anything along this theme, especially isolated islands.

[gbj]

this would be very cool. +1 for anything along this theme, especially isolated islands.

@dezren39 This is very much a WIP demo but you can see the fruits of #1422 at https://leptos-hackernews-islands.fly.dev/

(This does not work on Safari or iOS at the moment; I didn't realize Safari doesn't have requestIdleCallback.)

[nyabinary]

Some HTMX-like features would be very cool tbh

[gbj]

Some HTMX-like features would be very cool tbh

Which HTMX-like features are you looking for, how have you tried to use Leptos to achieve the same things, and what's gone wrong?