DioxusLabs/docsite

Improve documentation for realistic full-stack apps

ochrons opened this issue · 2 comments

ochrons commented

Any realistic web app will have things like database connections, or calling other services on the server side. Due to Dioxus "hijacking" the main function and sharing it with browser and backend code, it's not easy to see how one would create database connection pools or RPC clients. Any documentation from axum or tokio is not very useful, with the way the main is setup in Dioxus.

Second problem is how to pass these DB pools or RPC clients to Dioxus server functions, so that they can be used to fetch data from external services. This should be possible via Axum's State mechanism, but since we're not dealing with Axum directly, this needs to be properly documented with good examples.

Right now the only somewhat related example is the auth example, but even that is not really documented at all.

ealmloff commented

Related issues in the main dioxus repo:

ochrons commented

Here's a simple example that will trip people (at least me!) when doing some real server calls inside closures

#[component]
pub fn Like(post_id: String) -> Element {
    let mut likes = use_signal(|| 0);
    rsx! {
        button {
            onclick: move |_| async move {
                let new_likes = like(post_id).await.unwrap();
                likes.set(new_likes);
            }
        }
        "{likes} likes"
    }
}

this will not compile due to moving post_id into the closure.

The fix is to own it at just the right spot:

#[component]
pub fn Like(post_id: String) -> Element {
    let mut likes = use_signal(|| 0);
    rsx! {
        button {
            onclick: move |_| {
                to_owned![post_id];
                async move {
                    let new_likes = like(post_id).await.unwrap();
                    likes.set(new_likes);
                }
        }
        "{likes} likes"
    }
}

Alternatively using post_id: ReadOnlySignal<String> also works without the owning part.

Would be good to document this common scenario. Current documentation or any of the examples don't cover this.

  • 👍1