Dioxus 0.6 Roadmap #2223
Replies: 3 comments 6 replies
-
Let me know if there's any upstream
Likewise the form implementation we have now is very straightforward given the server fn POST approach and just using
In exchange I'm looking forward to stealing whatever you do here 😀 My sense is that Evan knows a lot more about WASM than I do. Needless to say all the rest looks amazing. You're crushing it! |
Beta Was this translation helpful? Give feedback.
-
|
Would love to see the roadmap features fleshed out in more detail, including problem description and a "definition of done", to make them more concrete. As examples, some features I would like to see for fullstack that are currently missing or difficult to use. Using a database in server functionsProblemCalling database from a server function requires a way to pass the database pool to the function. In Axum this can be done via the State extractor feature, storing the DB pool in the State and extracting it in the function. This is currently not possible for Dioxus server functions (or at least not documented how to do it). A workaround is to store the state in a Why is this important?For any realistic web application, fetching data in server functions is a must. The current approach is non-idiomatic, not documented and cumbersome. Definition of doneAs a developer I can extract the Axum State object in the server function to make DB calls. This feature is documented on the docsite and is used in an example application. Compile and deploy the server on different architectureProblemI use x64 based Windows computer but would need to run the application server on AArch64 Linux cloud server. I would like to build a Docker image for this platform on my computer, or in CI. If it is possible to build the fullstack server with a different target architecture, this is not documented. Why is this important?Being able to run the server on different architecture from the one that the developer or CI is using, is often needed as cloud providers support both ARM and x64 architectures. Definition of doneAs a developer I can define a build script using either This feature is documented on the docsite, including how to build a Docker container with the fullstack app. SSR with page specific metadata in
|
Beta Was this translation helpful? Give feedback.
-
|
+1 Using a database in server functions |
Beta Was this translation helpful? Give feedback.
-
|
I made an example for this particular case since I was also very interested if and how it is possible. |
Beta Was this translation helpful? Give feedback.
-
|
#2635 adds head elements that integrate with fullstack and #2515 makes it easier to provide context to server functions in fullstack. The docsite will be updated with these features with the release. It is much easier to build macos/ios on a mac device so cross platform builds will probably be a github action instead of a cross platform build. A build action is planned for 0.7 (pulled out + improved from here). |
Beta Was this translation helpful? Give feedback.
-
|
First of all, Rust is Amazing and Dioxus is making me love Rust every single day. Talking about Fullstack Application on Dioxus. As the project grows its super hard to go just use As it compiles web and server both and since hot reloading on dioxus is really amazing but just a small project with auth, few database libraries will make it frustrating to work. And majority of the time i feel myself working on styling frontend and sometimes alot of controller or abstraction layers to make use of it on server function. Because on WASM deployment of dioxus fullstack is really enclosed by dioxus i tried using https://github.com/DioxusLabs/dioxus/tree/main/packages/fullstack/examples/axum-desktop/ This example as a base where i have seperate client and server (exposing axum) and making it work on web. So if i am working on frontend i can just do
Thus just compiling the frontend and having hot reload on (Really helps me to excel development on Frontend Side) And if i want to run things on server I can do
We can just do use server_fn::axum::register_explicit;
register_explicit::<PostServerData>();
register_explicit::<GetServerData>();
let app = Router::new()
// Server side render the application, serve static assets, and register server functions
.register_server_fns();
// run it
let addr = std::net::SocketAddr::from(([127, 0, 0, 1], 8000));
let listener = tokio::net::TcpListener::bind(&addr).await.unwrap();
axum::serve(listener, app.into_make_service())
.await
.unwrap(); This way its seperated from frontend (This doesnt make it fullstack but if we fine tune it using some features we can make it work to serve dioxus application as well) So in minimal example it will be like #[cfg(feature = "web")]
// Hydrate the application on the client
dioxus_web::launch::launch_cfg(app, dioxus_web::Config::new().hydrate(true));
#[cfg(feature = "just_web")]
dioxus_web::launch::launch_cfg(app, dioxus_web::Config::default());
}Server.rs #[tokio::main]
async fn main() {
// build our application with some routes
use axum::http::Method;
use tower_http::cors::CorsLayer;
#[cfg(not(feature = "server"))]
{
// TODO: We will use this to build desktop application
use server_fn::axum::register_explicit;
register_explicit::<PostServerData>();
register_explicit::<GetServerData>();
let app = Router::new()
// Server side render the application, serve static assets, and register server functions
.register_server_fns();
// run it
let addr = std::net::SocketAddr::from(([127, 0, 0, 1], 8000));
let listener = tokio::net::TcpListener::bind(&addr).await.unwrap();
axum::serve(listener, app.into_make_service())
.await
.unwrap();
}
#[cfg(feature = "server")]
{
let origins = [
"http://localhost:8000".parse().unwrap(),
"http://127.0.0.1:8000".parse().unwrap(),
];
let cors = CorsLayer::new()
// allow `GET` and `POST` when accessing the resource
.allow_methods([Method::GET, Method::POST])
// allow requests from any origin
.allow_origin(origins);
let app = Router::new()
// Server side render the application, serve static assets, and register server functions
.serve_dioxus_application(ServeConfig::builder().build(), || VirtualDom::new(app))
.await
.layer(cors);
// run it
let addr = std::net::SocketAddr::from(([127, 0, 0, 1], 8000));
let listener = tokio::net::TcpListener::bind(&addr).await.unwrap();
axum::serve(listener, app.into_make_service())
.await
.unwrap();
}
}lib.rs use dioxus::prelude::*;
pub fn app() -> Element {
let mut count = use_signal(|| 0);
let mut text = use_signal(|| "...".to_string());
rsx! {
h1 { "High-Five counter: {count}" }
button { onclick: move |_| count += 1, "Up high!" }
}
}This way we can enjoy full dioxus fullstack with dx serve --platform fullstack Sorry for confusing comment but maybe we can enhance this experience natively on dioxus with some feature flags or seperate commands lol 😆 |
Beta Was this translation helpful? Give feedback.
-
|
While it would indeed be great for testing (with mockup requests when building frontend) |
Beta Was this translation helpful? Give feedback.
-
It sounds like the main benefit of separated builds is compile times. Once in place binary patching is working, most of the compile time benefits should be possible in the existing fullstack system. If a change requires new data from the server, you need to rebuild both the server and client. If it only requires changes to the frontend, then the frontend wasm can be patched in place without rebuilding the server |
Beta Was this translation helpful? Give feedback.
-
+1 |
Beta Was this translation helpful? Give feedback.
-
Dioxus 0.6 Roadmap
This release focus on polishing existing APIs, improving developer experience, upgrading fullstack, and the initial release of a component library.
Fullstack basics
Goal: expose as much as axum as possible to make fullstack more complete. Cater to real-world usecases like file uploads, SSG, streaming, and the dioxus-helmet replacement.
headandbody#1169head {}element in renderersComponent Library
Goal: a first-class component library for dioxus that takes into account mobile. Starting with solid foundations (like typesafe interfaces) and then exposing useful components on top. Documentation added to docsite.
#1483
Polishes - focus on CLI and documentation
Fix the various rough edges that have cropped up during 0.5 testing. Make hotreload more reliable across the board. Plugins, crash screens, smoother overall experience, better docs.
Native
Making stylo-dioxus interactive and at feature-parity with blitz. Replacing blitz with stylo-dioxus. Improvements to taffy that are necessary for html layout (like inline and style abstraction)
Styleobject in taffyBug Fixes/tweaks
A variety of bug fixes and tweaks that we want to do during this release that would normally get caught in a backlog.
prevent_defaultis not respected after bubbling events #1662CI/CD
Improvements to our continuous release process
Beta Was this translation helpful? Give feedback.
All reactions