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

Framework: Use warn module in place of react/lib/warn #787

Merged
merged 2 commits into from
Nov 26, 2015

Conversation

aduth
Copy link
Contributor

@aduth aduth commented Nov 25, 2015

Related: #786, #776

This pull request seeks to replace existing usage of the react/lib/warn module with our own existing warn module. This is a prerequisite for upgrading to React 0.14. Facebook has moved library modules to a separate package, which they warn against using.

Note: If you are consuming the code here and you are not also a Facebook project, be prepared for a bad time. APIs may appear or disappear and we may not follow semver strictly, though we will do our best to. This library is being published with our use cases in mind and is not necessarily meant to be consumed by the broader public.

https://github.com/facebook/fbjs

Testing instructions:

Ensure that no references remain for react/lib/warn.

/cc @blowery 11943-gh-calypso-pre-oss

@aduth aduth added Framework [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Nov 25, 2015
@aduth aduth self-assigned this Nov 25, 2015
@@ -5,9 +5,11 @@ var config = require( 'config' );

function warn() {
if ( config( 'env' ) !== 'production' ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can config change over the life of the app? we could make warn a noop and then override it if we're not in prod

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can config change over the life of the app? we could make warn a noop and then override it if we're not in prod

Sure, makes sense, and could shave a few cycles in production. What do you think about 726ccf7?

@blowery
Copy link
Contributor

blowery commented Nov 25, 2015

👍

@blowery blowery added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Nov 25, 2015

function warn() {
if ( config( 'env' ) !== 'production' ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use also process.env.NODE_ENV !== 'production' and the block should be removed during compilation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use also process.env.NODE_ENV !== 'production'

It's my understanding that we're not to use NODE_ENV and instead rely on the value specified in config, which is equal to the current environment's CALYPSO_ENV environment variable specified in the Dockerfile for each environment's build.

the block should be removed during compilation.

I'm not sure the uglifier is that smart. A common approach to achieve this is to use something like Webpack's DefinePlugin to replace occurrences of a text with false, which the uglifier would be smart enough to remove.

// 1. Variable comparison
var env = 'production';
if ( env !== 'production' ) {
    // Could be, but probably not removed by uglifier
}

// 2. Use `DefinePlugin` to replace `__DEV__` with `false`
if ( false ) {
    // Definitely removed by uglifier
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NODE_ENV is set in during the build process and will replaced by 'production' !== 'production', which will be removed by uglifier.

@aduth aduth force-pushed the update/react-lib-warn branch from 726ccf7 to 90b7cbb Compare November 26, 2015 16:29
aduth added a commit that referenced this pull request Nov 26, 2015
Framework: Use warn module in place of react/lib/warn
@aduth aduth merged commit 74e56c9 into master Nov 26, 2015
@aduth aduth deleted the update/react-lib-warn branch November 26, 2015 16:53
@lamosty
Copy link
Contributor

lamosty commented Nov 26, 2015

@aduth What about using Envify. It could reduce this code process.env.NODE_ENV !== 'production' into (e.g.) 'production' !== 'production' and then

By running this through a good minifier (e.g. UglifyJS2), the above code would be stripped out completely.

@aduth
Copy link
Contributor Author

aduth commented Nov 26, 2015

@umurkontaci @lamosty - Indeed, I had overlooked that we're already specifying a DefinePlugin in our Webpack configuration to replace the NODE_ENV with the value from the current configuration. As you both suspected, this would be replaced by the uglifier. I jumped the gun here, but I can plan to open a separate pull request for the optimization.

@lamosty
Copy link
Contributor

lamosty commented Nov 26, 2015

@aduth 👍

I'm sorry, I didn't notice that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants