Roadmap

[gbj]

Leptos Roadmap

This is intended as a fairly informal document to keep track of medium-to-large changes and the overall direction of development in the framework, and as an exercise to get some things that currently exist inside my head out onto paper. No promises that anything here that's not yet implemented will prove to be possible, let alone a good idea.

tl;dr Nothing here suggests significant breaking changes to an application you write today, although there may be smallish breaking changes that require semver bumps. I'm pretty confident in the current overall shape of the framework.

Docs/Guide effort

Ongoing: track progress in #364

0.2.0

I expect to begin a series of 0.2.0 prereleases soon. This is mostly due to some small breaking changes in the <ErrorBoundary/> and <For/> components, along with a changing import/prelude structure.

Remaining changes

• [ ] Reorganizing signals into traits (#490)
• [ ] Reorganizing Leptos exports/reexports into a less insane form
• [ ] Final tweaks to <ErrorBoundary/>/Errors API before finalizing 0.2.0

In-order streaming and async rendering

See #420 for additional detail.

• [x] Implement basic in-order HTML streaming
• [x] Implement non-streaming async rendering (trivial)
• [ ] Explore hydration: is it possible to begin hydrating while the stream is in progress and defer hydration of components that are not yet available in HTML until they arrive?
• [x] Add to server integrations
• [x] Deprecate preloaded_data_route approach, as this is a version of async rendering with worse DX

Projected merge: post-0.2.0, no breaking changes anticipated

Incremental changes to reactive system

• [ ] Refactor Runtime struct so that all reactive graph nodes (effects, signals, resources, etc.) can be stored in a single SlotMap, hopefully reducing Wasm binary size slightly, reducing the size of the Runtime created per HTTP request, and increasing memory efficiency on both client and server
• [ ] Refactor storage of thread-local data (create_effect and create_local_resource atoms, and running_effect) into a separate structure
• [ ] Upgrade wrappers on all other data from Rc/RefCell to Arc/RwLock, allowing the Runtime itself to be Send
  • [ ] reduces complexity of leptos_axum integration and increases performance by avoiding spawning a local Tokio runtime

Projected: post-0.2.0, no breaking changes

Rewrite of reactive-system internals

The reactive graph itself is currently extremely naive. We should be able to slightly improve performance and, much more importantly, reduce "glitches" like the diamond problem with a smallish rewrite. (For example, I'm pretty sure this should address #339) (Kudos to the Reactively library and Solid 2.0 reactivity.)

Release: 0.3.0 No breaking changes to user-facing APIs anticipated. Will require a bump in version number, because adopting less-glitchy behavior is a breaking change, if you rely on the glitches!

Partial hydration/islands architecture

• [ ] Create <ServerOnly/> and <ClientOnly/> components that opt out of hydration and code generation on the client or on the server (kudos to the Solid and Sycamore teams)
• [ ] Explore the possibilities of an architecture of reactive/dynamic "islands" within a sea of only-server-rendered content
• [ ] Explore hybrid nested routing (kudos to Solid)

DX/docs/testing improvements

Help wanted: Any of these items are things that other contributors could definitely work on fruitfully. I'm happy to add guidance to the extent that it's useful.

• Helping develop APIs for...
  • [ ] Route transitions in the router (#162)
• Adding examples
  • [ ] Patterns for global state management (#245)
  • [ ] Component-scoped styling using Stylers
• [ ] Developing component-level unit testing story (#489)
• [ ] Adding end-to-end testing for examples (even as part of our CI?) #210
• [ ] Explore hot-reloading of static nodes within your view macros without require recompilation (kudos to the Dioxus team)

[akesson]

You mentioned async rendering. A use-case would be when a Leptos server would fully render a page (pre-load data) when an SEO bot requests it and otherwise use the data once it arrives with server-side functions.

It would be fantastic if there were a way to remove the mutually exclusive features as well. cargo-leptos has to spawn the build into two threads and build into two different directories, duplicating all the artefacts and doubling the time for the first compile. I also think, but I have no concrete proof, that the rust-analyser is struggling with the mutual exclusive flags.

[gbj]

You mentioned async rendering. A use-case would be when a Leptos server would fully render a page (pre-load data) when an SEO bot requests it and otherwise use the data once it arrives with server-side functions.

Yes, exactly. We should even be able to deprecated your excellent preloaded-data-route work because async rendering would work with ordinary resources/suspense inside components. I'm pretty close on this, I just need to do the Axum integration and test it a bit.

It would be fantastic if there were a way to remove the mutually exclusive features as well. cargo-leptos has to spawn the build into two threads and build into two different directories, duplicating all the artefacts and doubling the time for the first compile. I also think, but I have no concrete proof, that the rust-analyser is struggling with the mutual exclusive flags.

Won't it always have to run two builds anyway, because of the two different targets? (Wasm + native?) Or I guess maybe it saves a bunch of work to compile with one feature set, even if it then compiles to two different targets?

I just honestly don't see a way to combine the server-side and client-side halves into one feature without big performance regressions, adding a generic like Sycamore's G: Html onto everything, or both. I'm open to it, I just don't have any ideas.

[akesson]

Regarding the mutually exclusive features: I promise that if you ever hear from me again about that, then it will be with a concrete proposal. Unfortunately, I don't have time for it now. I'm working on something really great for Leptos 😄. I hope to be able to present something next week.

[abishekatp]

Hi, in one of the above points you have mentioned that we need example for stylers. I have added some examples here. Please check out is it okay or we should improve it.

[gbj]

See #1147 for updated roadmap.