Leptos Islands vs Reactive Components

[R2rho]

First off, amazing work here! I'm really impressed with what you've put together, and it's given me a lot of insight to a project I'm working on. The ECS paradigm is new to me and I'm so intrigued with the possibilities outside of game development. Essentially I'm trying to build a fully running headless Bevy App with an integrated async runtime (bevy-tokio-tasks) which provides a similar starting point to build the idea of a Data Layer, and and axum server running inside of that async runtime. My goal was to build a Web UI in place of the regular bevy window, and use Leptos as the UI framework. I like Bevy's ECS paradigm as a way to manage sever side state (I'm hoping to build highly interactive multi-user web applications that primarily depend on an authoritative server for as much state management/syncing b/w clients as possible).

I've been testing some things, but I'm running into issues getting things to compile. I'm working on moving to a workspace setup similar to how you're doing it in your example app. I noticed in the readme you have two items that seem relevant:

1. Only Leptos Islands are supported - I'm assuming this is because you're focused on building static sites that don't hydrate on the server. Is there a technical reason you couldn't set this up to run a hydrated leptos app that runs on the client? I'm interested in potentially making this a feature for my apps, but not currently focused on it.
2. The "frontend" crate is separated from the "app" crate - It looks like you may have run into similar issues as I am currently, is this your workaround? Would you be willing to provide any more insight on why you had to implement it this way? I'm working on trying to mirror this currently to see if it resolves my issue, but you definitely are further along than me and have a lot more knowledge on the topic!

Thank you again for making this cool project, I definitely want to use it for some static sites in the future!

[NiklasEi]

Hey, thanks for reaching out

1. Yes, Cinnog is focused on generating static pages. For that use case islands make a lot of sense in my opinion. The classic example would be a blog. Do you mean have the ECS running on the server or on the client? In Bevy games both has been done, so technically it should be possible. Integrating the synchronous systems with an asynchronous web server like axum could get interesting though.
2. I started with https://github.com/leptos-rs/start-axum-workspace and then enabled SSG and islands features. The workspace just made it significantly easier to reason about dependencies and target platforms for each crate. One big learning was that NiklasEi/start-axum-workspace-islands-ssg@35d4ffb3bfa58926b2e7d680bdc1b355f3250855 is required for the hydration to work.

[R2rho]

Thank you for your help with that, yes primarily I'd like to have the ECS running on the server, and keep all state server side, minimizing the amount of state I have to manage on the client. I like the islands architecture for that. I thought about using HTMX to help maintain that paradigm as well, but I'm curious to see how far I can get with islands and SSR, with a bevy ECS datalayer handling all of the server state.

I was able to get something working, not quite there yet with the functionality of bevy as the datalayer, but I have a functioning way of getting a Leptos app inside of an async tokio runtime running within the context of the Bevy App. You can see the LeptosAppPlugin in crates/bevy_leptos. async-bevy-web

Here is a working example, originally cloned from your Cinnog example and modified to be a bit simpler. example

If there's any feedback you can provide, that would be amazing! Otherwise feel free to close this issue, again I appreciate your help and have learned a lot from your implementation! I'll be following your work closely!