Experiences with using dioxus live views #3378

brianmay · 2024-12-17T21:28:18Z

brianmay
Dec 17, 2024

I thought I would share my experiences I have had with live views here. As somebody with experiences writing personal projects with Phoenix Live views, but now prefers a type safe language such as Rust over Elixir.

Code is at https://github.com/brianmay/phone_db_rust/tree/23ffda33ed86a2def8d62e4c90bf72134e5e69ac - but note it is in a state of flux. I have pointed to the exact version of my project which is likely to become old quickly.

I have looked only at the 0.6.0 release. I have no idea if these solutions are good or correct, but they "work for me". It is possible some of these have already changed.

References to bug reports of known related issues appreciated.

Paths must start with a `/`

This was my first error. Turns out there is a problem with line here:

https://github.com/DioxusLabs/dioxus/blob/v0.6.0/packages/liveview/src/adapters/axum_adapter.rs#L48

let ws_path = format!("{}/ws", route.trim_start_matches('/'));

It will only work when the path is / otherwise it will generate an incorrect path.

| path | result | expected |
| /    | /ws    | /ws      |
| /xyz | xyz/ws | /xyz/ws  |

I think multiple calls to with_virtual_dom are, for every component. So we end up with a websocket for every top level component. I think this is different from phoenix live views which is able to share a single websocket amongst multiple top level components.

This enabled phoenix to do rapid changes between top level components.

I note the master version is a bit different so this may already be resolved.

trait defined for router without state

https://github.com/DioxusLabs/dioxus/blob/v0.6.0/packages/liveview/src/adapters/axum_adapter.rs#L36

impl LiveviewRouter for Router {

This makes it impossible to use on a Router that has called with_state().

Tested fix:

impl MyRouter for Router<AppState> {

Actually this probably should be a generic.

HTML Template code hard coded

https://github.com/DioxusLabs/dioxus/blob/v0.6.0/packages/liveview/src/adapters/axum_adapter.rs#L51-L62

        let index_page_with_glue = move |glue: &str| {
            Html(format!(
                r#"
        <!DOCTYPE html>
        <html>
            <head><title>{title}</title></head>
            <body><div id="main"></div></body>
            {glue}
        </html>
        "#,
            ))
        };

This may not always be suitable. e.g. it may be desirable to have my head elements. I have meta viewport.

I tried to generate this myself using rsx macros. This didn't work out though, I couldn't generate the head element from rsx, but also (perhaps not surprisingly) I couldn't convert the dom tree to a string for rendering. So I stack to a string based template as above.

https://github.com/brianmay/phone_db_rust/blob/23ffda33ed86a2def8d62e4c90bf72134e5e69ac/backend/src/lib.rs#L86-L103

App State and Path parameters

My App needs access to the State and Path parameters. I could not see how to do this with the existing code. So I ended up replacing the with_virtual_dom with my own function.

https://github.com/brianmay/phone_db_rust/blob/23ffda33ed86a2def8d62e4c90bf72134e5e69ac/backend/src/lib.rs#L124-L181

This currently has hard-coded values for AppState, this could be changed to a generic parameter.

I have not attempted to deal with Query parameters, I think this would be next on my list.

With my changes, I can do do:

Router::new()
        .with_my_app("/contacts/:id", ContactDetailView)

where the ContactDetailView is defined like:

pub fn ContactDetailView(props: Props<i64>) -> Element {

And this will listen on /contacts/:id and /contacts/:id/ws respectively and the html path will pass the required information to the websocket path.

In hindsight, wondering if this is the best approach. Might be better to pass the raw information to the component and handle the parsing in the component. Or something like that.

I note the master version is a bit different, but I think it doesn't yet solve the issue.

Websocket disruption

If websocket connection goes down, the website becomes non-responsive with no feedback to the user, and does not appear to try to connect again. This is not particularly good user experience.

Redirection

I have an object detail page that has a delete operation. But this of course means the page will turn into an error because the object doesn't exist anymore.

Need to be able to redirect to a different page from the component, but I can't work out how.

Infinite scrolling

Something I suspect is not currently possible without access to live scroll position and window size position information. Maybe this might help #2128

I think not even wasm front end code provides the required access yet though, although presumably I could fall back to JavaScript here (I thought I saw an issue on this but can't find it right now).

Conclusion

While live views work and seem to work well, I think there are currently some limitations. As described above.

Wondering if I should keep going with the live view approach, which is "good enough" for the limited audience my project (me) for now. Or if I should change to the wasm based front end, which I suspect might be more future proof.

I think the live views may require more changes to keep up with dioxus developments.

But before I even considered changing to wasm, I just wanted to document my experiences to this point. Which I have done here.

ealmloff · 2024-12-17T22:10:58Z

ealmloff
Dec 17, 2024
Maintainer

Thanks for taking the time to create this writeup! Some of these issues are fixed in the git version of dioxus, some could be fixed with better documentation, and some are more fundamental to the liveview approach. Unfortunately, Liveview is the only platform that handles events asynchronously which forces the API for communicating with the browser (through eval, onmounted, and event handlers) to be async. It also performs poorly with SEO and can be more resource intensive. Because of those limitations, we have been deprioritizing liveview as a platform and may drop support in the future. If we do drop support, some migration path for liveview-like apps will be available in fullstack like signals driven through websockets

Paths must start with a /

I think that should be fixed in #3341

App State and Path parameters

You can use the Router with liveview to parse the route and query under the base_path in your Dioxus.toml on the client. The git version of with_virtual_dom intercepts all paths under the route you pass in and parses the rest on the "client" websocket

HTML Template code hard coded

This is part of the reason dioxus in general is moving away from liveview. You can add elements to the head with the dioxus::document::* components after the websocket has loaded. If you care about SEO, fullstack prerenders everything on the server automatically unlike liveview

Redirection

I have an object detail page that has a delete operation. But this of course means the page will turn into an error because the object doesn't exist anymore.

Need to be able to redirect to a different page from the component, but I can't work out how.

You can use the navigator with the router to change to a different page: https://dioxuslabs.com/learn/0.6/router/reference/navigation/programmatic

3 replies

brianmay Dec 18, 2024
Author

You can use the Router with liveview

Oh, OK. I assumed the router wouldn't work here. Guess I assumed wrongly :-)

I probably should try the Router, I think it will be required if I do switch to wasm anyway.

And it does sound like wasm front end is the way to go (full stack might be even better but I had issues with this that probably deserve separate topic).

I don't care about SEO, this is an internal only system.

Am kind of curious though that Phoenix developers seem to think that live view is a good approach and I would have thought Elixir would use more resources then a Rust approach. But maybe that is due to tradeoffs, and Elixir not having good WASM support so they consider it more important.

brianmay Dec 18, 2024
Author

For a Live View, I need to get access to that State<...> also. As that contains important information such as configuration and the db pool.

brianmay Dec 18, 2024
Author

I notice that #3341 has:

route = "/*route".to_string();

But I think this is insufficient, it won't match /.

From, the documentation at https://docs.rs/axum/latest/axum/struct.Router.html:

Note that /*key doesn’t match empty segments. Thus:

/*key doesn’t match / but does match /a, /a/, etc.
/x/*key doesn’t match /x or /x/ but does match /x/a, /x/a/, etc.

So suspect it needs two routes, one for "/" and another one for "/*route".

brianmay · 2024-12-18T02:58:46Z

brianmay
Dec 18, 2024
Author

I find that there seems to be some confusion with life times I don't understand.

e.g. (cut down code)

pub fn PhoneCallListView(props: Props) -> Element {
    let mut edit_contact = use_signal(|| None);

    let mut new_phone_calls_signal: Signal<Vec<PhoneCallDetails>> = use_signal(std::vec::Vec::new);

    rsx! {
        for phone_call in new_phone_calls_signal.iter() {
            PhoneCallComponent {
                key: phone_call.id,
                show_actions: true,
                phone_call: phone_call.clone(),
                on_edit_contact: move |_contact_id| {
                    edit_contact.set(Some(phone_call.contact_id));
                }
            }
        }
    }
}

generates the error:

error[E0597]: `new_phone_calls_signal` does not live long enough
   --> backend/src/components/phone_calls.rs:169:27
    |
166 |       let mut new_phone_calls_signal: Signal<Vec<PhoneCallDetails>> = use_signal(std::vec::Vec::new);
    |           -------------------------- binding `new_phone_calls_signal` declared here
167 |
168 | /     rsx! {
169 | |         for phone_call in new_phone_calls_signal.iter() {
    | |                           ^^^^^^^^^^^^^^^^^^^^^^ borrowed value does not live long enough
170 | |             PhoneCallComponent {
171 | |                 key: phone_call.id,
...   |
178 | |         }
179 | |     }
    | |_____- argument requires that `new_phone_calls_signal` is borrowed for `'static`
180 |   }
    |   - `new_phone_calls_signal` dropped here while still borrowed

But If I remove the reference to phone_call.contact_id it works.

LATER: Oh, I see, I think there might be some sort of implied attempt of the rsx! macro (or maybe it is the nested component PhoneCallComponent that does it) to claim ownership of phone_call, which won't work, as it is a reference.

I think I have to lookup the id value outside the rsx! macro like:

pub fn PhoneCallListView(props: Props) -> Element {
    let mut edit_contact = use_signal(|| None);

    let mut new_phone_calls_signal: Signal<Vec<PhoneCallDetails>> = use_signal(std::vec::Vec::new);

    rsx! {
        for phone_call in new_phone_calls_signal.iter() {
            {
                let id = phone_call.id;
                rsx! {
                    PhoneCallComponent {
                        key: phone_call.id,
                        show_actions: true,
                        phone_call: phone_call.clone(),
                        on_edit_contact: move |_contact_id| {
                            edit_contact.set(Some(id));
                        }
                    }
                }
            }
        }
    }
}

This isn't as elegant, but at least it works.

EVEN LATER: I have a _contact_id parameter, I should just use that. I am an idiot :-)

But will post this regardless, it is a good example of the life time issue I experienced.

0 replies

brianmay · 2024-12-21T01:28:50Z

brianmay
Dec 21, 2024
Author

Does Dioxus full stack currently have any support for pushing data from the server to the client, e.g. via websockets?

I thought I saw something, but now I can't find it.

13 replies

ealmloff Dec 27, 2024
Maintainer

You don't need to add server_fn as a dependency. dioxus includes it in the prelude

brianmay Dec 28, 2024
Author

OK.

Can confirm now that the example works.

Example is stupid, it ignores the result of the unbounded_send and keeps sending long after the client has gone. Easy to fix.

I guess that works by a simple HTTP feed that keeps sending data, instead of using a websocket. Is this correct?

brianmay Dec 28, 2024
Author

If I understand this correctly, is suitable for character stream only, not suitable as is for encoding/decoding json objects (because client not guaranteed to receive entire json object in one next() call).

Please correct me if I got this wrong :-)

ealmloff Dec 29, 2024
Maintainer

#3396 fixes the unbounded send error.

If I understand this correctly, is suitable for character stream only, not suitable as is for encoding/decoding json objects (because client not guaranteed to receive entire json object in one next() call).

The StreamingJson encoding uses serde_json to encode and decode each chunk of the stream into a concrete type.

Please correct me if I got this wrong :-)

HTTP streaming is chunked with a built in delimiter. It is not a single uninterrupted stream of binary data. More info here

brianmay Jan 4, 2025
Author

I completely missed the StreamingJson. Will have to try that. Seems to require JsonStream, no surprise here.

What would also be interesting is to try to configure the client to automatically connect on start and reconnect if the connection goes down. I imagine it shouldn't be too hard, but I am use to unexpected problems :-)

websockets support still desirable, but this in theory should solve the problem for everything but my complicated MQTT based app (which I have no desire or time to port from yew anytime soon...)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Experiences with using dioxus live views #3378

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 3 comments 16 replies

{{title}}

Paths must start with a `/`

App State and Path parameters

HTML Template code hard coded

Redirection

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Experiences with using dioxus live views #3378

brianmay Dec 17, 2024

Paths must start with a /

trait defined for router without state

HTML Template code hard coded

App State and Path parameters

Websocket disruption

Redirection

Infinite scrolling

Conclusion

Replies: 3 comments · 16 replies

ealmloff Dec 17, 2024 Maintainer

Paths must start with a /

App State and Path parameters

HTML Template code hard coded

Redirection

brianmay Dec 18, 2024 Author

brianmay Dec 18, 2024 Author

brianmay Dec 18, 2024 Author

brianmay Dec 18, 2024 Author

brianmay Dec 21, 2024 Author

ealmloff Dec 27, 2024 Maintainer

brianmay Dec 28, 2024 Author

brianmay Dec 28, 2024 Author

ealmloff Dec 29, 2024 Maintainer

brianmay Jan 4, 2025 Author

brianmay
Dec 17, 2024

Paths must start with a `/`

Replies: 3 comments 16 replies

ealmloff
Dec 17, 2024
Maintainer

Paths must start with a `/`

brianmay Dec 18, 2024
Author

brianmay Dec 18, 2024
Author

brianmay Dec 18, 2024
Author

brianmay
Dec 18, 2024
Author

brianmay
Dec 21, 2024
Author

ealmloff Dec 27, 2024
Maintainer

brianmay Dec 28, 2024
Author

brianmay Dec 28, 2024
Author

ealmloff Dec 29, 2024
Maintainer

brianmay Jan 4, 2025
Author