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

Umbrella: New Devtools API #5306

Closed
jimfb opened this Issue Oct 28, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@jimfb
Contributor

jimfb commented Oct 28, 2015

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:

  • #5302 - User wants to emit custom warnings when potentially slow operations are executed during render.
  • #4302 - Users want to clear warnings for unit testing and/or hot-reloading
  • #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.
  • #5924 - Users want to fail unit tests when specific warnings fire, like an invalid checksum warning.
  • #6239 - User wants to render errors using a pluggable logging framework.
@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Oct 29, 2015

Member

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.

Member

gaearon commented Oct 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@slorber

slorber Nov 27, 2015

Contributor

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...)

Contributor

slorber commented Nov 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@benmills

benmills Jan 15, 2016

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.

benmills commented Jan 15, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Oct 3, 2017

Member

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.

Member

gaearon commented Oct 3, 2017

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.

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