Disable react strict mode on third party libraries

[israelKusayev]

I started to use react strict mode in my project.

But I'm using third party libraries (like old react-bootstrap).

Is it possible to disable the strict mode on those libraries specifically, or disable strict mode to all third party libraries?

[israelKusayev]

Also for the new update is it possible to disable the "Rename componentWillMount" messages to third party libraries?

[threepointone]

If React made these exceptions, then it wouldn’t be “strict” at all :) so no, I don’t think React will skip third party libraries for warnings.

Could you tell me why you’re using strict mode if you cannot commit to the guarantees just yet? I would recommend you not use third party libs that aren’t strict mode compatible. Alternately, don’t use strict mode if your project isn’t ready for it.

[israelKusayev]

It's a big project so I cannot update the libraries that we are using.
But we still want to update react version and /or using strict mode for our code.

If react team can add the ability to disable strict mode for those libraries it would be great

For example

  <React.StrictMode thirdParty={false}>
       // code goes here
  </React.StrictMode>

[threepointone]

React can’t detect which components are “third party”. These other libraries should release versions which either rename the method names, or refactor with the suggestions in the warning message. Based on github activity, I notice a lot of libraries are already doing this.

Is there anything critical for you in the 16.9 release that warrants an upgrade of React? I would consider the task of upgrading React libs to be dependent on that.

[gaearon]

You can always put <StrictMode> more granularly than around the whole app. Start from some smaller sections that don't contain outdated third party components, and gradually move it upwards as they get fixed.

We don't currently offer a more granular way to opt into strict mode. But keep in mind is that its whole purpose is to tell you whether the app is compatible with future planned changes. So if you silence it for third party components, you don't gain that much in terms of guarantees.

[hatton]

So if you silence it for third party components, you don't gain that much in terms of guarantees.

Right, but while we're waiting for 3rd party components to catch up, it is very nice to immediately catch if our code starts violating anything.

You can always put more granularly than around the whole app.

Thanks for that suggestion, that's what we're doing for now, but you can't mark a component as strict if any of its descendants are not, so it's of limited use. I assume it wouldn't be feasible to instead be able to fence off sections that are not yet strict, so that they are easy to find? E.g.

<StrictMode enabled={false}> or <BreaksStrictMode>

That way we could put much more of the code under the Strict checking.

[MaximilianLloyd]

Any update on this?

[gaearon]

Why would you expect an update on this?

There are no plans to support more granular strict mode. The purpose of the strict mode is to offer a guarantee about the behavior of the subtree. I very much understand the temptation for partial guarantees but that undermines the whole principle. With this behavior when you look at StrictMode you wouldn’t know whether the subtree is strict-compatible, or something else overrides it two components below. So this makes the feature useless as the project grows.

[starikcetin]

This would be very useful indeed. 3rd part libraries are cluttering my console output with all sorts of strict mode warnings.

[epikhighs]

3rd party libraries are outside of my direct control so I wouldn't want to be barraged by warnings I can't do anything about. The only thing to do for 3rd party library warnings is to wait and see if there'll be a fix or switch the library for an alternative (assuming a suitable alternative exists).

The other issue is that strict mode seems to break functionality.

I'd love to keep using strict mode, but having to manually include every component except for the one component isn't very practical (at least for me).

[bvaughn]

The other issue is that strict mode seems to break functionality.

To me, that indicates that Grid has a bug and StrictMode is making the bug's behavior occur in a reproducible way. That's one of the main purposes of strict mode and how it works.

[epikhighs]

Yea, I understand that, which is great for the author of the 3rd party lib, but not much I can do about it other than disable react strict mode for my entire app :)

[bvaughn]

Which is probably what you should do (at least for now). StrictMode is providing a valuable signal in this case: the library you're using in your application is probably not going to work well in concurrent mode.