multiwindows, hide or close? Can static ever be used?

[young kestrel]

I have an odd bug where I am "switching" between two windows on logout. Close the main window, open the login window. Done in reverse order to not accidentally make tauri think we ran out of windows and it should shut down.

This works usually, expect in one case where for no reason at all it explodes the process entirely. This has got me thinking, what is even the use for static windows? I don't know any software in the world that has more than a single window open by default in a static manner. Not a single one. With my current understanding of windows in tauri, this means that the "static windows" features is practically vestigial, and given enough time 100% of apps will have 0 static windows. So my natural conclusion was that I must have a skewed understanding, because it would be odd to have a feature that basically does not do contribute to any use case.

So, my question is, given 3 windows: main, login, and authorize, where the first 2 are "static", in the sense that they are knowable in advanced but I need to dynamically decide on which one to present to the user and switch between them. The last one being "dynamic"(?) in the sense that I don't know the external URL it's going to load until runtime. How should I manage their state?

My current approach I find very clunky, in the setup function I have this:

let handle = app.handle();
app.listen_global("oauth://token", move |_| {
    let h = handle.clone();
    tauri::async_runtime::spawn_blocking(move || {
        if h.windows().contains_key("main") {
            println!("main window found, continuing");
        } else {
            println!("opening main window");
            View::main(&h).build().expect("Failed to build main window");
        }

        if let Some(login_window) = h.get_window("login") {
            println!("closing login window");
            login_window.close().expect("Failed to close login window");
        };
    });
});

let handle = app.handle();
app.listen_global("oauth://logout", move |_| {
    let h = handle.clone();
    tauri::async_runtime::spawn_blocking(move || {
        if h.windows().contains_key("login") {
            println!("login window found, continuing");
        } else {
            println!("opening login window");
            View::login(&h)
                .build()
                .expect("Failed to build login window");
        }

        if let Some(main_window) = h.get_window("main") {
            println!("closing main window");
            main_window.close().expect("Failed to close main window");
        };
    });
});

View being a sort of map I've made for the windows since a reference them in a few locations and I close and build them so yeah.

Note that the token event works great, and the logout makes the app melt down when it calls main_window.close().

Should I actually use hide instead of close? I really hope theres a better way to work with windows because this is quite painful even without me creating bugs..

[young kestrel]

since hide only makes the window invisible (I think), it's essentially like a less-efficient, more buggy, and much more convoluted way to manage the windows if they have any sort of lifecycle. Because now the developer needs to manually implement the lifecycle, calling setup and cleanup in response to arbitrary markers, which can and in time will result in stale, foreign, or premature state encounters.

On the other side, creating them requires bending over backwards

[young kestrel]

Please advise me 😦

[limber flare]

I don't think there is a definitive answer to this; it's entirely dependent on developer preference and feature support. For example, minimise-to-tray will complicate things because it's possible to have 0 windows. Many real-world apps don't even touch the main window when showing a login dialog; Visual Studio Code and Git HTTPS authentication is one such example.

[young kestrel]

This works in situation where there is anything to show in the main window when the user is not logged in

as in, login as opt-in. Not login as access

[limber flare]

Wouldn't you just show the main window always first then have a login button somewhere?