RFC: Deprecate `next/head` #8981

devknoll · 2019-10-07T16:45:53Z

devknoll
Oct 7, 2019

Goals

Support Concurrent Mode in React and Streaming Server-Side Rendering
Improve load times by decoupling <head> and <body>

Background

The next/head pattern makes it very easy for your components to configure the rendered <head>, but it has some major drawbacks:

HTML is blocked until after the entire React tree is rendered

Since <Head> can appear anywhere in your component tree and in turn modify the <head> tag, Next.js must render your entire tree before it can start sending any HTML to the client.

This leads to a chunk of dead time where the browser does nothing other than wait for the server, when it could have otherwise been loading and processing resources like CSS or JavaScript.

Non-deterministic in Concurrent Mode

<Head> depends on the side-effects of rendering happening in a specific order:

function ComponentA() {
  return <Head><title>Light is a: wave</title></Head>
}

function ComponentB() {
  return <Head><title>Light is a: particle</title></Head>
}

export default function MyPage() {
  return (
    <>
      <ComponentA />
      <ComponentB />
    </>
  )
}

In Concurrent Mode, ComponentA and ComponentB can be mounted in any order, leading to a non-deterministic value for <title>.

Proposal

Next.js should allow you to define a <head> once per page by exporting a head component:

// pages/index.js
export default function Index() {
  return <span>Hello World</span>
}

export function head() {
  return (
    <>
      <title>Index</index>
    </>
  )
}

<Head> should continue to work, but Next.js should warn in development mode that you are missing out on some features and that it may be removed in a future version.

An exported head component should receive the same props as the page component, so you can support e.g. dynamic titles with getInitialProps:

// pages/post.js
export default function Post({ post }) {
  return <Post post={post} />
}

Post.getInitialProps = async ({ req }) => {
  const post = await getPost(req.query.id)
  return { post }
}

export function head({ post }) {
  return (
    <>
      <title>{post.title}</title>
    </>
  )
}

You can use components to continue sharing and composing pieces of your <head>:

// pages/index.js
import CommonHead from '../components/common-head'

// ...

export function head() {
  return (
    <>
      <CommonHead />
      <title>Index</title>
    </>
  )
}

// components/common-head.js
export default function CommonHead() {
  return (
    <>
      <meta name="author" content="My Co, Inc.">
    </>
  )
}

With the exception of <title>, most pages already tend to render the same <head>. By making this explicit (via the head component), rather than a side-effect, your websites can take advantage of new Next.js and React features to improve your user's experience.

kachkaev · 2019-10-07T17:02:02Z

kachkaev
Oct 7, 2019

Feeding the right value into export function head() would be quite challenging in some cases. Imagine a product page which makes a GraphQL query somewhere in the middle of the React tree to fetch product details. When the query is resolved, the value into next/head title is added. How would it be possible to do the same given two totally isolated top-level functions?

2 replies

pie6k Mar 4, 2021

Maybe some sort of "ClientSideHead" that is ignored during ssr

fabb Apr 11, 2022

Nope, we need the SSR response to contain all the info in the head for SEO.

devknoll · 2019-10-07T17:11:28Z

devknoll
Oct 7, 2019
Author

@kachkaev I think that's a legitimate concern. One idea was to allow only <title> to be set dynamically (via e.g. a standalone <Title> component that is used like next/head, or a useTitle hook). Then the title you set in the head component is more like an initial/fallback.

This would work for e.g. Google which will use the document.title when crawling JavaScript pages, but might not work for other crawlers. But this also wouldn't be compatible with Concurrent Mode if you've got multiple in use...

Curious if you think that would be sufficient or if you have other thoughts/ideas 😄

0 replies

raghav0622 · 2019-10-07T17:13:12Z

raghav0622
Oct 7, 2019

Feeding the right value into export function head() would be quite challenging in some cases. Imagine a product page, which makes a GraphQL query somewhere in the middle of the React tree to fetch product details. When the query is resolved, the value into next/head title is added. How would it be possible to do the same given two totally isolated top-level functions?

Well whenever we query anthing on server with graphql there are two possibilities, there is an error or there is no error. The solution you are looking is simply solvable by useEffect hook

Also it covers for almost every case with single mo

export default function Page() {
  const { loading, data } = useQuery()

  useEffect(() => {
    if (data.value) {
      document.title = data.value
    }
  }, [data.value])

  return (
    // Your JSX
    <>
      <h1>Yo</h1>
    </>
  )
}

export function head({ initialTitle }) {
  return <><title>{initialTitle}</title></>
}

0 replies

Janpot · 2019-10-08T13:18:57Z

Janpot
Oct 8, 2019

You can use components to continue sharing and composing pieces of your <head>:

Maybe this could be made a bit more ergonomical by also allowing an export function head() from _app.js? The result of which would be added to the <head> of every page. I feel like it complements the existing function of _app.js rather well.

Edit:

🤔 Or rather, I guess the complementary would be a component that wraps the rendering of the page's head.

// _page.js
export function Head({ Component, pageProps }) {
  return (
    <>
      <meta name="viewport" content="width=device-width, initial-scale=1" />
      <Component {...pageProps} />
    </>
  )
}

0 replies

devknoll · 2019-10-08T17:12:59Z

devknoll
Oct 8, 2019
Author

I think passing a Head prop to _app.js (that represents the Component's head) and requiring it to be rendered in a custom head is probably reasonable. Curious what you think @timneutkens

0 replies

Jessidhia · 2019-10-09T04:30:19Z

Jessidhia
Oct 9, 2019

Various linting tools assume that only functions that start with use or an uppercase letter are components/allowed to call hooks; choosing the exact name to use probably needs some study.

0 replies

emirotin · 2019-10-18T15:35:45Z

emirotin
Oct 18, 2019

A bunch of use-cases to add to @kachkaev's note:

we store the links to our favicons and similar site-wide stuff in Prismic (headless CMS)
similar to title various meta tags (og:, description, etc.) can depend on the dynamic page-specific content (also stored in Prismic in our case)

We want these things to be fetched in the component's getInitialProps and be part of the initial SSR, and we don't want them to disappear after the CSR.

0 replies

devknoll · 2019-10-18T16:10:12Z

devknoll
Oct 18, 2019
Author

@emirotin The Head function receives the same props as the page component, so you can use getInitialProps for any fetching:

function MyPage() {
  // ...
}

MyPage.getInitialProps = async () => {
  const metadata = await fetchFromPrismic(/* ... */)
  return { metadata }
}

export default MyPage

export function Head({ metadata }) {
  return <>{convertToTags(metadata)}</>
}

This will work both on initial SSR and CSR.

0 replies

jstcki · 2020-03-20T09:56:10Z

jstcki
Mar 20, 2020

Considering #9160, would it make sense to return HTML attributes from the new GS(S)P methods?

E.g.

// Or getServerSideProps
export function getStaticProps({ params }) {
  return {
    htmlAttributes: {
      lang: params.lang
    },
    props: {...}
  }
}

0 replies

RStankov · 2020-03-23T15:54:53Z

RStankov
Mar 23, 2020

Why is separate export needed? Can the head function be attached to the default export similar to how getInitialProps is done:

function MyPage() {
  // ...
}

MyPage.getInitialProps = () => {
  // ...
}

MyPage.getHead = (/* props returned from getInitialProps */ ) => {
  // ..
}

Couple of benefits of this approach:

will keep the symmetry in the API.
will make it easy to build tools on top of Next.

I have something createPage in my applications which looks like this:

export default createPage() {
   query: GRAPHQL_QUERY,
   // ...

   head: (dataFromQuery) => { /* ... * /}
   component: (dataFromQuery) => { /* ... */ }
}

0 replies

mxck · 2020-03-27T07:06:41Z

mxck
Mar 27, 2020

@devknoll you have typo in first code example in Proposal section (<title> have wrong closing tag)

0 replies

resir014 · 2020-05-20T04:17:53Z

resir014
May 20, 2020

Why is separate export needed? Can the head function be attached to the default export similar to how getInitialProps is done:

@RStankov Based on this reply on the getStaticProps() and the getServerSideProps() proposal (which also uses the same pattern), it will help when doing tree-shaking during build time. Having the function attached to the component makes it harder to tree-shake the bundle.

0 replies

RStankov · 2020-05-20T09:29:27Z

RStankov
May 20, 2020

@resir014 Haven't thought about that. Makes sense.

It makes total sense for getStaticProps and getServerSideProps because you might want to use those without loading the whole component.

Is there a case where you would want to load head without wanting to load the page component as well?

0 replies

mohsen1 · 2020-09-07T12:56:53Z

mohsen1
Sep 7, 2020

I wrote another RFC that gets into how to send <head> before the rest of the document. Rendering <head> before the rest of document is a challenge that I didn't touch in my RFC. My focus is delivering the list of assets and <link> elements in the <head> as soon as possible to the browser. That part of <head> is more deterministic and less dependent on rendering path with exception for <link >s of required chunks.

I'm glad you are all interested in solving this problem. There are many assumptions in Next.js architecture that makes this a difficult problem to solve.

0 replies

fabb · 2020-12-08T07:21:32Z

fabb
Dec 8, 2020

How would this work with styled-components? It needs to render he whole tree to be able to collect the styles which it then writes to the head.

https://styled-components.com/docs/advanced#nextjs

0 replies

ariesclark · 2021-04-09T17:11:12Z

ariesclark
Apr 9, 2021

Any update on this proposal or is this now stale?

0 replies

awareness481 · 2021-12-13T14:20:31Z

awareness481
Dec 13, 2021

Has it been decided whether this will be the approach with the server streaming implementation?

0 replies

balazsorban44 · 2022-11-07T18:03:42Z

balazsorban44
Nov 7, 2022
Maintainer

Hi, head.js as documented here has landed as part of the app/ directory, introduced in Next.js 13. We appreciate the feedback provided by @devknoll and the community!

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: Deprecate `next/head` #8981

{{title}}

Replies: 18 comments 2 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

RFC: Deprecate next/head #8981

Goals

Background

HTML is blocked until after the entire React tree is rendered

Non-deterministic in Concurrent Mode

Proposal

Replies: 18 comments · 2 replies

devknoll Oct 7, 2019 Author

devknoll Oct 8, 2019 Author

devknoll Oct 18, 2019 Author

balazsorban44 Nov 7, 2022 Maintainer

RFC: Deprecate `next/head` #8981

Replies: 18 comments 2 replies

devknoll
Oct 7, 2019
Author

devknoll
Oct 8, 2019
Author

devknoll
Oct 18, 2019
Author

balazsorban44
Nov 7, 2022
Maintainer