components
components copied to clipboard
[Feature Request]: Allow React component for SideNavigation & TopNavigation Links
Description
Hi,
I'm using Gatsby and it work pretty well, my only concern is that Gatsby has the component Link which is super optimized for users
The <Link> component drives a powerful performance feature called preloading. Preloading is used to prefetch page resources so that the resources are available by the time the user navigates to the page.
We use the browser’s Intersection Observer API to observe when a <Link> component enters the user viewport and then start a low-priority request for the linked page’s resources. Then when a user moves their mouse over a link and the onMouseOver event is triggered, we upgrade the fetches to high-priority.
I can feel the speed difference by using it or not. Is it possible to add an option to define a react component directly for the link ?
Something like:
<SideNavigation
items={[
{
type: "section",
text: "Collections",
items: [
{
type: "cmp",
value: <Link href="/page2"></Link>,
},
{
type: "link",
text: "Test",
href: "/test",
},
],
},
...
<TopNavigation
identity={{
href: "/",
cmp: <Link href="/page3"></Link>,
}}
...
Or is there a way to do it already?
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
- [X] I checked the current issues for duplicate requests
Hey, thank you for reaching out and bringing this use case to our attention.
We currently don’t support using a custom component as a side navigation item. Allowing this does seem like a sensible addition to the side navigation component, however we don’t have any plans for making this change at the moment.
I will keep this issue open to collect any additional feedback or use cases.
Thanks! RC
Hi!
Following up on this issue:
You can programatically navigate by using the onFollow
property in the SideNavigation (which is fired when an anchor is clicked) and onItemClick
in the TopNavigation component.
For example:
import { navigate } from "gatsby"
<SideNavigation
onFollow={(event) => {
event.preventDefault();
navigate(event.href);
}}
/>
This should still allow Gatsby to use the linking enhancement features that you mentioned (preloading, prefetching).
I'd like to piggyback off of the this issue with my request for the TopNavigation
having a component.
I'd like to be able to add a custom login widget that Telegram offers: https://core.telegram.org/widgets/login
This has been translated into React/Typescript but since the TopNavigation
component doesn't support custom components, I'm unable to add it into the navigation or point to one of the Button
elements to do this business logic done in the component.
Would be nice to have an easy interface to make use of react router with cloudscape.
Simply allowing value: <Link href="/page2"></Link>
as the OP suggests does not work, because we need to apply additional styles for hover and active states.
Applying styles like .side-navigation a {...}
is unsafe because we do not know what is going on inside react-router library. You may even use a different routing library after all. We cannot make any assumptions what is inside that <Link>
This leaves us with the current onFollow={event => { event.preventDefault(); navigate(event.href); }}
. May look a little verbose, but it allows us to not worry about every new router version, because everything works same way as before.
If you want us to prioritise this feature request, it needs some solid reasons, not just aesthetic preferences
Not directly related to this but I have a use case where I'd like to be able to disable links in the SideNavigation.
Further to the above I'm using Next.JS and for navigation I use the following and it works well for me
onFollow={(event) => {
event.preventDefault()
push(event.detail.href)
}}
Simply allowing
value: <Link href="/page2"></Link>
as the OP suggests does not work, because we need to apply additional styles for hover and active states.Applying styles like
.side-navigation a {...}
is unsafe because we do not know what is going on inside react-router library. You may even use a different routing library after all. We cannot make any assumptions what is inside that<Link>
This leaves us with the current
onFollow={event => { event.preventDefault(); navigate(event.href); }}
. May look a little verbose, but it allows us to not worry about every new router version, because everything works same way as before.If you want us to prioritise this feature request, it needs some solid reasons, not just aesthetic preferences
That's very fair and I agree with your stance. The styling issues would require a lot of thinking/effort--the juice probably isn't worth the squeeze.
I think the onFollow
API provides a good hint of what else could be done: more callback props. The only one that I think is notably missing is something approaching onHover
, which would enable programmatic optimistic prefetching . Prefetching is something handled out of the box by the NextJS framework link component (and I imagine for other frameworks as well).