Criticism: Using Custom Router Harms Adoption

[isosphere]

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.¹

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

Footnotes

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 ↩

[ctron]

So the main projects contributing so far to this project make use of the nested router, because it's required. I am absolutely open adding an additional implementation, but I would want to keep the current implementation the default.

The main reason for that is that it automatically gets more test coverage.

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

So maybe that's something to improve. If you could give some feedback on what would have helped you to have an easier introduction, that would definitely be helpful, and might let others benefit too.

The reason why it's enabled by default in patternfly-yew is that, if you want to use it, it's easier to get started. Assuming there would be an additional implement (e.g. based on yew-router) it might indeed be an idea to disable both by default and let the user choose.

[isosphere]

So the main projects contributing so far to this project make use of the nested router, because it's required. I am absolutely open adding an additional implementation, but I would want to keep the current implementation the default.

The main reason for that is that it automatically gets more test coverage.

I can appreciate that motivation; more testing makes better libraries. It will hurt adoption, though, but I can accept if that is a lower priority.

yew-nested-router has effectively has one contributor; If you disappear, we will either have to fork and maintain that dependency or convert back to yew-router, which is a technical debt time-bomb.

patternfly_yew feels less risky in the same sense because the use-case is much more clear and broad: people want component libraries and are willing to contribute to them (I maintain yew-bootstrap and get lots of helpful contributions, and it's tiny!). We don't have many of them for Rust. I don't think the same motivation exists for router alternatives.

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

So maybe that's something to improve. If you could give some feedback on what would have helped you to have an easier introduction, that would definitely be helpful, and might let others benefit too.

The reason why it's enabled by default in patternfly-yew is that, if you want to use it, it's easier to get started. Assuming there would be an additional implement (e.g. based on yew-router) it might indeed be an idea to disable both by default and let the user choose.

I agree that your quickstart would get people up and running quickly - if they are starting from scratch.

My project began using a different component library, and when it got in my way I swapped it out for yours. However, I was using yew-router and had plenty of routes defined. I had to then try to convert my yew-router implementation to match yew-nested-router. I abandoned the attempt, but luckily found that I could opt-out.

I anticipate that others will approach the project this way; they'll have existing yew projects, which means yew-router implementations, for better or worse.

If we are to improve onboarding for yew-router users, I think we'd need to write a guide specifically targeting the topic of converting a project to yew-nested-router from yew-router. With before/after snippets, explanatory text, and finally some motivating examples that demonstrate why it was worth it (i.e.: nesting). I think a blog-post style would work well.

I'd be happy to contribute to this documentation with writing, editing, and testing, though you're probably the one that would have to get it started, as you understand both routers better than anyone.

[ctron]

Fair arguments. And as I said, I would definitely welcome an additional router implementation. I just don't have the need or time to do this. This would need to come as a contribution.

And if that's the case, I am also fine to make both routers opt-in. Just to make it easier to let the user choose.

I am also ok with starting to write some kind of blog post/documentation as you suggested. That might be a good idea anyway. I will put it on my "to do" pile :)

[ctron]

Btw, not sure you know, but there's a also a Matrix channel: https://matrix.to/#/#patternfly-yew:matrix.org … might be quicker for some chats.