Roadmap (0.4 and beyond)

[gbj]

(This supersedes the roadmap in #501.)

Roadmap

Goals for 0.4.0

• [x] Axum extract function (#1093)
• [x] Improvements to <For/> algorithm (#533, #1146)
• [x] Remove need to explicitly call ::register() on server functions (#613, #1154)
• [x] Consider using anyhow in <ErrorBoundary/> and friends (#1228)
• [x] Support generics in multiple positions in components (#949, #1023, #1109)
• [x] Breaking: Reorganize features so that nightly is an opt-in feature and stable is default (#1007, #1227)

Goals for 0.5.0

• [x] Breaking Changing reactive ownership model to avoid manual use of Scope and cx everywhere (#802, #918)
• [x] (?) Breaking: Use new bind: syntax for typed children on <For/> and possibly other control-flow components, when useful (#1140)

Non-breaking improvements

• [ ] Reduce number of hydration keys and component comment markers (#972, #903)

Goals for Future

• [x] 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 (#832)

Ongoing work with no breaking changes

• [x] Website.
• [x] Completing the guide/book.
• [x] Adding end-to-end testing for examples as part of our CI (#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?