Replies: 1 comment
-
As a side note, having the // ============================================================
// Current implementation
// ============================================================
export const useTags = () => {
const router = useRouter()
const routeMeta = useRouterState({
select: (state) => {
return state.matches.map((match) => match.meta!).filter(Boolean)
},
})
// De-duping and parsing logic...
}
export function HeadContent() {
const tags = useTags()
}
// ============================================================
// Exposed implementation
// ============================================================
export const useTags = (macthes: unknown[]) => {
// De-duping and parsing logic...
}
export function HeadContent() {
const routeMeta = useRouterState({
select: (state) => {
return state.matches.map((match) => match.meta!).filter(Boolean)
},
})
const tags = useTags(routeMeta)
} So we have the freedom to provide what we want to the hook, including the original data! // User implementation
export function CustomHeadContent() {
const { customTags } = useCustomTagsFromContext()
// Retrieve the router tags as well.
const routeMeta = useRouterState({
select: (state) => {
return state.matches.map((match) => match.meta!).filter(Boolean)
},
})
// Provide our own tags, and still benefit from tanstack deduping / parsing logic.
const tags = useTags([...routeMeta, ...customTags])
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'd like to play with the default
HeadContent
component, to add some custom interactions with the document head (ability to override / modify some tags in my components, through a custom context).It is tempting to rewrite the default component with extra logic, as its definition is already fairly simple and elegant.
The
Asset
component is exported, but theuseTags
hook is not. This makes replicating the component complicated, as the internal logic ofuseTags
is complex (~150 lines).Request
Would it be possible to simply export this hook, along with the
Asset
component ? It would make expanding the original logic a breeze, without the need to override everything.The current workaround (Processing accumulated route context) kind of works, but is implementation heavy and not fit for every use case.
Also my demand is only for this specific hook, but maybe some more internal methods / types could be exposed to make the router customization easier, without breaking any existing APIs ?
Beta Was this translation helpful? Give feedback.
All reactions