Using <StrictMode /> causes error in console: Warning: Unsafe lifecycle methods were found within a strict-mode tree

[JustFly1984]

I'm using gatsby as example environment for new google maps api, and I need to test it with SSR, but at the same time I need to test it in strict mode, but instead of showing me errors in my own code, it errors out on gatsby's code.

Warning: Unsafe lifecycle methods were found within a strict-mode tree:
    in StrictMode (at pages/index.js:66)
    in IndexPage (created by PageRenderer)
    in PageRenderer (created by JSONStore)
    in JSONStore (created by EnsureResources)
    in ScrollContext (created by EnsureResources)
    in RouteUpdates (created by EnsureResources)
    in EnsureResources (created by RouteHandler)
    in RouteHandler (created by Root)
    in div (created by FocusHandlerImpl)
    in FocusHandlerImpl (created by Context.Consumer)
    in FocusHandler (created by RouterImpl)
    in RouterImpl (created by LocationProvider)
    in LocationProvider (created by Context.Consumer)
    in Location (created by Context.Consumer)
    in Router (created by Root)
    in Root
    in _default (created by HotExported_default)
    in AppContainer (created by HotExported_default)
    in HotExported_default

componentWillMount: Please update the following components to use componentDidMount instead: SideEffect(NullComponent)

Learn more about this warning here:
https://fb.me/react-strict-mode-warnings

[jonniebigodes]

That's because and i'm just guessing, as i'm not knowledgeable of all the gatsby code, but deep down somewhere in some components used in gatsby, or one of the libraries you're using, there might be some now deprecated methods being used. And correcting that might take some time as the React ecosystem is constantly evolving and not only gatsby, but other libraries also, will take some time to adjust to this constant evolution.
But does the build break, or does it succeed but with the warnings?

[JustFly1984]

I hadn't tried to build for prod with yet, it warns in develop only.

[jonniebigodes]

I'm inclined to say that this will happen in production mode as well.
You're probably going to get the same warnings.
But it's currently working, even with the warning? That's what i wanted to ask aswell

[JustFly1984]

It is warning, not an error, so yes it does not crush an app by itself, but if you have scripts, which tracking errors, it spams a system with false negatives, and google lighthouse audit tool lowers your performance grade. Console.log is not cheap IO operation, especially with warnings.

[jonniebigodes]

@JustFly1984 i'm going to cc this issue to two people more knowledgeable of the library so that they are made aware of the issue if you don't mind.
@pieh @DSchau , care to chime in if you can.

[pieh]

but instead of showing me errors in my own code, it errors out on gatsby's code.

Actually that's not entirely true - it shows "stack trace" which originates from gatsby runtime, but actually end up in your code:

Warning: Unsafe lifecycle methods were found within a strict-mode tree:
    in StrictMode (at pages/index.js:66) // this points to your code
    in IndexPage (created by PageRenderer) // IndexPage is your page component
    in PageRenderer (created by JSONStore)

componentWillMount: Please update the following components to use componentDidMount instead: SideEffect(NullComponent)

Do You perhaps use https://github.com/gaearon/react-side-effect ? (or maybe some of your dependencies use it)

[JustFly1984]

Nope, I was using static gDPFS, not WillMount. I do not have willMount in my code, cos I did refactor it since long time ago, and search across project proves it.

@pieh id you can se the stack trace starts in StrictMode and bubbles (unwraps) from the button to the top the component tree, so the strict mode is the root element of IndexPage, and after that it is gatsby's code till AppContainer and HotExported_default, which is react-hot-reload's code, and errors out exactly react-hot-loader

in Root
    in _default (created by HotExported_default) Gatsby
    in AppContainer (created by HotExported_default)
    in HotExported_default's component

[pieh]

I did some quick investigation with default starter and in this case it seems like react-helmet (which uses react-side-effect, which in turns still use cWM) is likely suspect here. If I don't use react-helmet (or move it outside of StrictMode), warning disappear. There is issue in react-side-effect about usage of cWM - gaearon/react-side-effect#54 .

We don't use componentWillMount or react-side-effect in gatsby code, so there's little we can do about this (aside from looking for alternative for react-helmet and porting default starters to something else)

[JustFly1984]

Thank you, this explain some stuff, I'm pretty sure it will be fixed by Dan asap

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[JustFly1984]

not stale

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

Thanks again for being part of the Gatsby community!

[JustFly1984]

Please reopen

[diegohaz]

I'm getting the following error with StrictMode:

Warning: Legacy context API has been detected within a strict-mode tree: 
    in StrictMode (created by App)
    in App
    in _default

Please update the following components: ScrollContext

Learn more about this warning here:
https://fb.me/react-strict-mode-warnings

It seems that ScrollContext is still using legacy context:

gatsby/packages/gatsby-react-router-scroll/src/ScrollBehaviorContext.js

Lines 14 to 16 in bddfcbc

	const childContextTypes = {
	scrollBehavior: PropTypes.object.isRequired,
	}

Related:

Reminder: mere presence of legacy context API in the tree puts everything below it onto a slower code path. It is worth migrating away from.

— https://twitter.com/dan_abramov/status/1097866569701621763

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[JustFly1984]

not stale

[PutziSan]

One option would be to use react-helmet-async as an alternative to react-helmet.

[JustFly1984]

How to deprecate react-helmet for gatsby projects?

If for example somebody imports helmet from sub-dependencies gatsby, it could break the build. This looks like breaking change issue.

[selbekk]

This issue will now hit a lot more consumers, due to React 16.9.

[JustFly1984]

Yes, this bummers me to update react in my gatsby project

[JustFly1984]

nfl/react-helmet#426

[mi-na-bot]

Has anybody looked into using react-helmet-async as a replacement? This article by the creator cites the lack of activity at react-helmet as a major motivation for a fork:

https://open.nytimes.com/the-future-of-meta-tag-management-for-modern-react-development-ec26a7dc9183

At this point react-helmet-async has as many weekly downloads as react-helmet.

https://www.npmjs.com/package/react-helmet-async

[wardpeet]

@Sever1an thank you for taking the time to write such a comprehensive post. Sadly we're not able to move away from react-helmet in v2 as it would be a breaking change with gatsby-plugin-react-helmet.

What's the reason to use StrictMode?

[narration-sd]

underline this, no??

It would be nice if react-helmet updated its dependencies such that they all used the new name UNSAFE_componentWillMount(). This would eliminate the warnings for now, and generally push the day when a react update breaks gatsby builds into the future.

Hope you can do this now - just think of all the time we spend tracking this down...and the support load for other systems or benefitting by upgrading Gatsby - thanks

[josephrexme]

It's hard to tell what the rationale is from this thread. I tried using react-helmet-async and it seemed to have been just fine without errors. The probably then became that gatsby-plugin-react-helmet still relies on react-helmet and would lead to stale page titles. I had to go back to react-helmet since it still behaves as expected except I would like to get rid of the console warning.

[aoberoi]

@Sever1an thank you for taking the time to write such a comprehensive post. Sadly we're not able to move away from react-helmet in v2 as it would be a breaking change with gatsby-plugin-react-helmet.

@Sever1an out of curiosity, why are we not open to a breaking change to fix this issue? i took a look at several other plugins in the repo, and as of now they are not all synchronized on major versions, so that reason seems unlikely.

[nikoladev]

@Sever1an thank you for taking the time to write such a comprehensive post. Sadly we're not able to move away from react-helmet in v2 as it would be a breaking change with gatsby-plugin-react-helmet.

What's the reason to use StrictMode?

@wardpeet Would it be possible to add this to the milestone for the next major version?

[robinmetral]

Seems like parts of the community is already opting for gatsby-plugin-react-helmet-async.

To move forward with this issue, maybe we could update the docs, switch the default meta tag manager in the official Gatsby starters... and eventually deprecate gatsby-plugin-react-helmet in favor of gatsby-plugin-react-helmet-async? What do you think?

[mi-na-bot]

The async helmet plugin should be official, not community contributed. react-helmet is vaporware

[m-allanson]

This problem has been fixed by the release of React Helmet v6. gatsby-plugin-react-helmet has already been updated to support the new version (thanks to @stevenocchipinti 🎉).

To update your site:

• install gatsby-plugin-react-helmet@3.2.2 or later
• install react-helmet@6.0.0 or later
• ensure you're using a named import when you import the Helmet component import { Helmet } from "react-helmet"

[simnalamburt]

@diegohaz FYI, discussion of gatsby-react-router-scroll is being continued at #21231, and a PR regarding this issue has been opened! #21626

[simnalamburt]

As @m-allanson pointed out, react-helmet has released a new release fixing this issue. I think this issue is now OK to be closed

[JustFly1984]

@simnalamburt closing

[cutiful]

@m-allanson but it wasn't fixed? Getting

Warning: Using UNSAFE_componentWillMount in strict mode is not recommended and may indicate bugs in your code. See https://reactjs.org/link/unsafe-component-lifecycles for details.

* Move code with side effects to componentDidMount, and set initial state in the constructor.

Please update the following components: SideEffect(NullComponent)

with react-helmet 6.1.0 and gatsby-plugin-react-helmet 4.14.0.

See nfl/react-helmet#548 and the comments on nfl/react-helmet#426 (after it was closed). Helmet still depends on react-side-effect, which still uses UNSAFE_componentWillMount: gaearon/react-side-effect#54.