Update isReferentiallyTransparentFunctionComponent.js

[oliviertassinari]

I'm wondering about the purpose of !Component.propTypes.
Using propTypes is quite a popular pattern.
If it's only here in order to get proper warning in dev mode, that shouldn't prevent us from
instantiation less react components in production.

Hopefully, we can use babel-plugin-transform-react-remove-prop-types to increase the number of referentially transparent components

[wuct]

If we use the babel plugin to remove propTypes in production, there is no need to check the environment here again, right?

[oliviertassinari]

If we use the babel plugin to remove propTypes in production

• Removing 100% of the propTypes in production is quite challenging. You need either lib author do wrap their propTypes with a process.env.NODE_ENV === 'production' or make babel parse the all node_modules folder. Not that easy.
• It's a micro-optimization, but even if you remove 100% of the propTypes, I think that checking !Component.propTypes is a lost CPU cycle in production.

[wuct]

I get your point now. IMO !Component.propTypes should be removed in production, because React doesn't check propTypes in production.

[wuct]

Will this line be considered dead code and be eliminated in production?

[istarkov]

swapping on process.env.NODE_ENV === 'production' || !Component.propTypes will avoid getting the propTypes

[oliviertassinari]

@istarkov I agree that it would be better. I believe that uglify-js is smart enough to remove those if (!foo.bar || true) expression but that may not be true with other minifier, they may keep it.

[wuct]

Yes, I've just tried UglifyJS, both true || foo and foo || true work.

[wuct]

LGTM. I'd like to know how @acdlite and @istarkov think.

[istarkov]

I like this PR 👍 to merge

[wuct]

@oliviertassinari thanks!

[oliviertassinari]

Awesome, thanks 🎉 !

Any plan to do a release? The last one was 144 days ago.
We use the decoration pattern quite extensively at @doctolib.
Performance is important for us. @neoziro is even investigating toward combining all those HoCs into a single one with recompact while keeping the same API.

[gregberge]

I agree with @oliviertassinari, the project is moving slowly, that's why we are building "recompact" apart recompose. We will switch to it and use it in production. If the experimentation is a success, we could consider merging the two projects in the future.