Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

with-react-helmet bug in production mode #3534

Closed
1 task done
damianfrizzi opened this issue Jan 5, 2018 · 4 comments · Fixed by #6235
Closed
1 task done

with-react-helmet bug in production mode #3534

damianfrizzi opened this issue Jan 5, 2018 · 4 comments · Fixed by #6235
Labels
good first issue Easy to fix issues, good for newcomers

Comments

@damianfrizzi
Copy link

I tried to implement React Helmet for our project and noticed a bug when running in production mode.
React Helmet doesn't initialize on the very first request after starting the application. But it initializes correctly on each subsequent request (SSR & CSR).
I cloned the minimal with-react-helmet example and I can confirm that the issue appears there, too.

image

  • I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

React Helmet should initialize correctly on the first request that was made.

Current Behavior

As described above, React Helmet doesn't initialize correctly on the very first request.

Steps to Reproduce (for bugs)

  1. Clone with-react-helmet
  2. npm install
  3. npm run build
  4. npm start
  5. Check the DOM/page source
@damianfrizzi damianfrizzi changed the title with-react-helmet has a bug in production mode with-react-helmetbug in production mode Jan 5, 2018
@damianfrizzi damianfrizzi changed the title with-react-helmetbug in production mode with-react-helmet bug in production mode Jan 5, 2018
@JeromeFitz
Copy link
Contributor

I do not believe this is limited to with-react-helmet. The initial server render seems to set the tone and subsequent requests are good to go. (Tried looking for issues to reference, will continue to see if I can link any here.)

I can absolutely reproduce this following your steps (and have).

Accessing the same URL from a separate machine and even network does not reproduce the behavior though (SSR source), which I believe limits it to the very first render of a newly built deployment (and the client-side JS compensates for it, in that exact case).

@damianfrizzi
Copy link
Author

@JeromeFitz do you maybe have any workaround for this? Right now we're extracting the desired information to render the correct meta information from this.props.__NEXT_DATA__ which is quite hacky...

@JeromeFitz
Copy link
Contributor

JeromeFitz commented Jan 29, 2018

@damianfrizzi On my end, I am okay with its current behavior (wherein, I can only verify this happens on the first render from the server itself). So at this time, I have no workaround or way to suggest addressing this.

@Ephem
Copy link
Contributor

Ephem commented Feb 10, 2019

I dug into this and found out what caused the behaviour.

The default metadata was declared inside of <Head> in _document.js. This document gets rendered by renderToStaticMarkup after getInitialProps. So when Helmet.renderStatic was called, the default metadata had not yet been rendered. This got flushed on the next request.

Solution is to move the declaration of any default metadata into _app.js instead. This gets rendered before Helmet.renderStatic is called and so works correctly.

@lock lock bot locked as resolved and limited conversation to collaborators Feb 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Easy to fix issues, good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants