tracking and then updating a signal in on_cleanup causes Router to rerender

[luxalpa]

Describe the bug
When using a tracked signal in on_cleanup of a page component, and then updating it from within that component for example via request_animation_frame or set_timeout then once navigation switches to a different page, the Router renders the new page twice.

Leptos Dependencies

leptos = { version = "0.5.1", features = ["nightly"] }
leptos_meta = { version = "0.5.1", features = ["nightly"] }
leptos_actix = { version = "0.5.1", optional = true }
leptos_router = { version = "0.5.1", features = ["nightly"] }

To Reproduce
Use the code below, go to the HomePage (default), then click on "Random" to switch to the other page. In the console, there will be these log messages:

RandomPage
HomePage cleanup
RandomPage

use leptos::*;
use leptos_router::*;

#[component]
pub fn App() -> impl IntoView {
    let ctx = create_rw_signal(());

    provide_context(ctx);

    view! {
        <Router>
            <main>
                <nav>
                    <a href="/">"Home"</a>
                    <a href="/random">"Random"</a>
                </nav>
                <Routes>
                    <Route path="" view=HomePage/>
                    <Route path="/random" view=RandomPage/>
                </Routes>
            </main>
        </Router>
    }
}

#[component]
pub fn RandomPage() -> impl IntoView {
    logging::log!("RandomPage");
    view! {
        <div>"RandomPage"</div>
    }
}

#[component]
pub fn HomePage() -> impl IntoView {
    let ctx = expect_context::<RwSignal<()>>();

    on_cleanup(move || {
        logging::log!("HomePage cleanup");
        ctx.track();

        request_animation_frame(move || {
            ctx.update(|_| {});
        });
    });

    ()
}

Expected behavior
Ideally, the code in on_cleanup should only be using untracked functions I guess, but this bug is very difficult to track down. I don't know why this tracking causes the Router to end up rerendering the page. It shouldn't, I think.

[gbj]

Uhhh interesting. So I guess it would be possible to internally untrack before running cleanups. This just adds an overhead to every on_cleanup. I don't understand why you'd ever need a tracked reactive access in an on_cleanup but I can understand it's easy to do inadvertently.

Just so I'm clear: is there a use case in which you actually want something tracked in a cleanup function, or was it tracked accidentally?

[luxalpa]

This was tracked accidentally due to #1880. Probably it would be sufficient if there was some kind of diagnostic in debug mode for this case.

[gbj]

Sounds like a good idea.

[gbj]

For the sake of clarity, I checked and it doesn't rerender the Router or Routes, just the RandomPage.

It was also easy and very cheap (a single Cell access and re-set) to ensure these are never tracked; two lines of code and it seems to have fixed the example issue, so I'll just leave it there.

[luxalpa]

Ah, that's very nice. Thanks a lot! <3