Update to Leptos 0.5

[DylanRJohnston]

The example will need to be updated to work with this, but I just wanted to share what I had done. I couldn't get the static assets from KV working so I just commented it out as I'm using Cloudflare Pages.

[9oelM]

@DylanRJohnston is this complete? if so I can help something about serve_static_from_kv, perhaps by doing sth like separating it out as a feature flag, and I can review the code as well

[DylanRJohnston]

I’m currently using it in my project, but after looking more carefully at the current Axum and Actix implementations I don’t think it properly supports the new static site generation nor providing additional context (such as the worker env).

Any help with the KV stuff would be appreciated so it can continue to support that even though I’m using Pages.

[9oelM]

Yeah no problem. I will try to add to your work once i have some time. Thanks.

[DylanRJohnston]

I was actually just investigating using https://github.com/logankeenan/axum-cloudflare-adapter. I think it might be a more sustainable approach than maintaining a Cloudflare <-> Leptos adapter with the rate of progress of Leptos (0.6 was just released recently). All axum-cloudflare-adapter needs to do is bridge cloudflare with axum, and then the existing upstream maintained axum to leptos adapter can be used.

Although Axum does have some annoying Send bounds on things which makes it difficult to work with in a WASM context as all JsValue's are not Send. The benefit though is that you can use all the tower and tower-http middleware. As the router built into worker-rs is pretty lacking.

[DylanRJohnston]

Further more, the #[event(fetch)] macro from worker-rs doesn't do much other than renaming your function to fetch and wrapping the raw web_sys::Request / etc arguments into their wrapper types in workers-rs so if you just used the raw #[wasm_bindgen(js_name = "fetch")] instead you might be able to use https://crates.io/crates/axum-browser-adapter/0.2.1