Routing not working for very simple case

[jason-johnson]

Describe the bug
I have what seems to me a pretty simple routing setup but the routing does not happen. The URL is set up correctly and if I click in the browser bar and press enter, the page goes to the right location but the application does not do this move by itself, it only changes the URL. I'm running the code under trunk serve. I have tried a tags and A tags but neither worked.

Leptos Dependencies

leptos = { version = "0.7.0", features = ["csr"] }
leptos_router = "0.7.0"

To Reproduce
Steps to reproduce the behavior:

1. Open the code
2. Run trunk serve --open
3. Click on a link in the menu
4. See that the URL changes but the page does not load

Expected behavior
The page should go to the new location and load that page when the link is clicked.

Additional context
The code in question is here. It is part of a larger workspace and if someone wants to try it out, there is a devcontainer configuration that should run right in Github (codespaces) if desired.

[jason-johnson]

Ok, so I was able to get the page routing working by putting a simple "counter" on one of the pages. It seems that if there is no reactive code then the whole runtime doesn't load.

[gbj]

It seems that if there is no reactive code then the whole runtime doesn't load.

It couldn't be this, because the router itself is full of reactive code, but this does make sense in light of what the actual solution was here.

This bug was due to an interesting corner case involving the confluence of three things:

1. The structure of the two pages was identical except for the text nodes, which meant that had the same type signature; this means that rather than simply replacing one with the other, the framework tried to rebuild the DOM in place (which is good!)
2. As an optimization to cut down on compile times, I had added an InertElement that would compile chunks of the view with no reactivity to a plain HTML string.
3. However, I hadn't thought to implement the rebuild() method correctly for InertElement, as the need to do so only arises in... this specific corner case, when the structures of the views are identical and there's no reactivity the

Adding a counter presumably prevented the relevant part of the UI from counting as "inert" and so removed that optimization, or it changed the structure of one of the pages and therefore the type, removing the other optimization — either one, or PR #3370, should fix it.