Criticism: Using Custom Router Harms Adoption

I have about a month of patternfly_yew use under my belt and have found my end-products with it to be excellent. However, getting there is unnecessarily painful.

This quickstart project uses a custom router (https://github.com/ctron/yew-nested-router) rather than the ubiquitous yew_router.

I have read the issue that spawned the creation of the custom router and I am happy to believe that it is a technically superiour router. However, it is not a drop-in replacement for yew-router, and in my experience, pretty challenging to understand.

Trying to learn this custom router and the particulars of this component framework at the same time is high-friction.

I don't believe that this example project requires the custom router. I am using yew_router with my project without any pain so far.

Suggestion

yew-nested-router should not used for this quickstart project.[^1]

I'm happy to work on a PR to make this happen, but only if this change would be welcome.

[^1]: I think it should also be opt-in for the parent project, patternfly_yew, rather than opt out with default-features = false; a component library shouldn't (IMO) dictate router choices - it makes it much more difficult to switch to and away from, making the perceived technical debt much higher

No files or tests are named. Start by reviewing the quickstart's router dependency and usage, then check how the parent patternfly_yew project exposes router features. Done means the quickstart no longer requires yew-nested-router and works with yew-router, with the parent router choice remaining opt-in if that scope is accepted.