Change ReactPropTypes invariant's to console.warn.

[cpojer]

This changes it so that PropTypes logs to the console via console.warn instead of throwing through an invariant. This means that PropType-validation can be stripped out in production to potentially speed up React apps. Since the code only logs to the console from now on, the logic that is followed is the same in prod and dev and actual errors will come up the same way.

Currently this is gated by DEV but we might want to add another magical constant.

90 % of the time making this was to fix all the unit tests to expect console.warn calls instead of expecting the functions to throw.

[vjeux]

I really like this change!

cc @yungsters @jordwalke @petehunt @sebmarkbage

[cpojer]

Just realized ReactErrorUtils is not a good place for this, how about an 'error' module that lives next to invariant?

[sebmarkbage]

This should use console.warn and probably be called something like warn. I spent a day once trying to figure out why an error wasn't interrupting code flow because it looks like it's thrown.

A rename to a short stand-alone name would be good. It's really nice to be able to statically analyze these.

[cpojer]

I had this as 'warn' before but decided error is better. Warnings in the console don't really cry for much attention and if something goes wrong with your PropTypes I think it is better to tell you about it in RED.

[cpojer]

Changed to an error module.

[yungsters]

Since the console methods already support string formatting, why do we have to re-implement it?

[cpojer]

@yungsters we wan't to be able to analyze this module and maybe strip it out in prod.

if (condition) console.warn(…); is harder to analyze than warning(condition, …)

[cpojer]

discussed with @sebmarkbage in person, we decided to call this module warning.

[sebmarkbage]

@cpojer we don't need to do the string parsing since console.warn supports %s in the same way.

console.warn(format, ...args);

[cpojer]

Hah, I never knew about this.

[sophiebits]

Even in old IE?

[sebmarkbage]

shim it :)

It's cool because it uses toString so we get custom formatting. But the inspector could turn that part of the string into a link to an object that can be inspected.

[petehunt]

yessssss

[yungsters]

Wait, what? Why was this merged?

[plievone]

You may have already considered this, but weakInvariant or warnInvariant or something would preserve the semantics, now the condition may get reversed if read/written quickly.

Also in ReactPropTypes.js s/shouldThrow/shouldWarn/ ?

[cpojer]

@sebmarkbage, @jeffmo and I only came up with softInvariant which we didn't like. I really like weakInvariant! @sebmarkbage what do you say?

[zpao]

Please don't call something an invariant if you're not treating it as such.

[...] an invariant is a condition that can be relied upon to be true during execution of a program, or during some portion of it. It is a logical assertion that is held to always be true during a certain phase of execution. – Wikipedia

[plievone]

@zpao It is a strange situation to be in if propTypes are not relied to be valid, problems will ensue? The validity is just checked via other means (console.warn) than throwing immediately. I just pointed out that as of now the condition to warning may get easily reversed, as in comment #912 (comment)