Umbrella: New Devtools API

[jimfb]

As per conversation with @sebmarkbage, it would be cool if React emitted events that allowed any attached devtools to listen for relevant events occurring in the core. The emitted events could be just descriptive enough that devtools could track whatever internal state it wants. For instance, a devtool could track perf by seeing how long various operations are taking (marked by start and end of the operation). Or a devtool could emit useful warnings (all our core warnings could be rolled into a devtools module/package, and by tracking state internally we could avoid routing the only-useful-for-warnings data throughout the core).

Anyway, the following are relevant:

• Prevent a function to be called from within render #5302 - User wants to emit custom warnings when potentially slow operations are executed during render.
• Add hooks into the warning output for unit tests and other use cases #4302 - Users want to clear warnings for unit testing and/or hot-reloading
• Perf actual React components #5254 - Users want to track/monitor calls to shouldComponentUpdate and get statistics on the results. Gather other per-component statistics like number of setState calls and renders.
• save flag someplace if checksum was invalid #5924 - Users want to fail unit tests when specific warnings fire, like an invalid checksum warning.
• Pipe console logs to specified logger #6239 - User wants to render errors using a pluggable logging framework.

[gaearon]

For instance, a devtool could track perf by seeing how long various operations are taking (marked by start and end of the operation).

I remember somebody trying to call Perf.start() and Perf.stop() before and after Flux Store dispatches, but the problem was that React batched setState() calls, and so the actual work was performed after. So if an API is provided for more accurate measurements, there should be a way to track the actual work associated with setState calls in particular period.

[slorber]

You probably refer to this issue @gaearon #3611

Also want these events to know when something bad happen, so that I can display a big fat red message to developers to fix their bug (because they usually don't look that much the console and ship softwares with console.error messages...)

[benmills]

I hit a similar issue around not getting prop type validation warnings as mocha reran my tests on file system changes. While resetting state would be a fine solution I would strongly prefer to get programatic access to prop type validation failures.

The real thing that, I believe, @glenjamin and I want to do is write tests that assert no prop type validations have failed. If we had the ability to clear ReactElementValidator.loggedTypeFailures we still would have to mess with console.warn to find validation errors.

[gaearon]

In the end the extensible system we tried to design didn’t really work out. Even with very few warnings, it was quite slow in development, and also pretty complicated.

We can design a better one now with the new engine, but I’d like to begin with scoping it down just to a warning hook first. We can track that in #4302.