Hi there, thanks for the PR. You are correct about the maintenance issues, and I do think that the current state allows for easer maintenance, but as you point out yourself the code to make these components is so minimal, I don't think it adds a lot to provide them (saves a line or two of code) but it also obscures the underlying implementation which is useful to folks in and of itself. i'd say this may be unneeded complexity but others may disagree :)

Thanks for the PR! Yeah – I don't think the pre-built components add too much, and it's just a pain to keep things in sync and handle PRs for adding/removing new components. Maybe some HoC-ification might make sense, but as currently implemented, I don't think we want to add these components.

Thanks for your input. The only real vouch I had for adding the components came from the fact that it seems really likely that most users of the library will implement those components in this simplest form. In fact that is why they need the library and therefore the very first thing they might look for in the documentation are things like ButtonLink or NavItemLink.

But then your arguments are reasonable. Between having all user implement the same exact wrapper or provide them with a simple implementation well enough for their needs I was wondering what was the most reasonable choice. So I will keep it separate and close the PR.