<Meta> tags are considered to be the same and overridden if the key (string) prop matches.
That's it. <Title> is still always replaced.
Why
No complicated/surprising heuristics.
Easier to maintain.
Explicit and opt-in.
Less surface for bugs.
Why not userland
Server-side is a pain to get right, yet critical, especially for open-graph and other metadata (crawlers won't always execute JS).
Duplicated logic - this library already needs to override <Title>, so userland de-duplication of meta tags would essentially add the same logic.
I personally would expect my framework to handle this.
Other popular frameworks like Next.js do exactly this. Fun fact, I only found out about this after writing this proposal. Other examples: Remix, Nuxt.
Status
Work in progress, need to figure out the tests but the basic implementation is done. Also, I think the key prop will currently be set as an attribute, so probably need to exclude it before rendering. Couldn't test yet because of local env issues.
Open questions
Is key an appropriate/descriptive prop name for this?
Should this behavior apply to other tags? (I think probably not)
What this changes
<Meta>tags are not replaced by default.<Meta>tags are considered to be the same and overridden if thekey(string) prop matches.That's it.
<Title>is still always replaced.Why
Why not userland
<Title>, so userland de-duplication of meta tags would essentially add the same logic.Status
Work in progress, need to figure out the tests but the basic implementation is done. Also, I think the
keyprop will currently be set as an attribute, so probably need to exclude it before rendering. Couldn't test yet because of local env issues.Open questions
keyan appropriate/descriptive prop name for this?Related
34 #40