Codesandbox-client: Remove StrictMode by default or move it into App.js

[eps1lon]

🌈 Feature

We recently see more and more issue on the Material-UI repo that are caused by confusion about implicit StrictMode (also in this repository #3598)

It should be more obvious that StrictMode is used.

Either remove it completely (I'm not sure it's such a great tool for prototyping which is usually pretty hacky and not strict! at all) or move it into App.js. I think the biggest problem is that users see App.js by default and rarely need to touch index.js

[MichaelDeBoey]

Going to close this one as this is expected behavior, since the CRA-team has added StrictMode by default in v3.4.1 (see facebook/create-react-app#8558).

[eps1lon]

I understand that this is expected. I was also suggesting moving it into App or some other improvements to detecting StrictMode (maybe logging a hint in console).

The issue is not that it does apply StrictMode. The issue is that this is likely missed. @MichaelDeBoey Could you please consider opening this again until others had a chance to voice their opinion?

[MichaelDeBoey]

@eps1lon If you look at the PR's commits, you'll see that StrictMode was first added in app.js instead of index.js (facebook/create-react-app@af82b63).
As @ianschmitz requested, @gaearon removed it from app.js and added it to index.js.

[eps1lon]

Sure but there was not rationale for it. Probably to catch side-effects inside App. But moving StrictMode inside a non-descriptive index.js causes issues. Let's hope this doesn't continue to be an issue as I think the use cases for create-react-app and codesandbox are different.

[gaearon]

I'm not sure it's such a great tool for prototyping which is usually pretty hacky and not strict! at all

I don’t think “hacky” or “not hacky” is relevant here. You could make a similar argument about JS "use strict". And yet I’m pretty sure CodeSandbox runs your code in JS strict mode by default. As it should.

Strict mode doesn’t have to do with “being hacky”. It has to do with compatibility with future versions of React. Strict Mode has been available as opt-in for literally two years (yes, since March 29, 2018). By now, most major libraries we’ve seen have successfully upgraded to pass its checks.

Before we can enable it in React by default (with a possible opt-out strategy), we need to push the ecosystem a bit further. Environments like CodeSandbox and CRA are a great way to do that.

We think now is a good time to do it because most new versions are already compatible and we want regular users (and not just React pros) to start filing issues for the warnings they see. I recognize that as a library author it can be frustrating. But I imagine most library authors already know about strict mode violations in their libraries. So either there needs to be a plan to fix it, or (if there is no plan) it might make sense for people to start moving to libraries that don’t have these violations. (For example, a few libraries of mine are impossible to fix — so I explicitly ask people to use some different.)

I see what you’re saying about explicitness. However, that is very much the point. Someday it will become a default. We’re just previewing what would happen then on a smaller scale. If we just put it into App, people will remove it immediately (“what is this?”) and this won’t achieve any purpose. The purpose is to start preparing for strict mode to be on, always. Not teach users to remove it in order to use some library.

There is an escape hatch (remove it) at this point and that’s good to have. Certainly, you can tell that to people in the issues. But that just ignores the bigger problem which will eventually bite them when they upgrade React. The real solution is to get these libraries fixed.