Add ReactNativeOperationHistoryDevtool to track native operations

[gaearon]

This is extracted from #6046 and implements a new devtool that tracks native operations.

[ghost]

@gaearon updated the pull request.

[ghost]

@gaearon updated the pull request.

[ghost]

@gaearon updated the pull request.

[ghost]

@gaearon updated the pull request.

[sebmarkbage]

Hm. What would you think about just passing the new "props" object instead of onNativeOperation or onSetValueForProperty? Like onPropsChanged(debugID, props). Would that be sufficient?

How the native "props" get applied is a fast moving implementation detail of each renderer.

[sebmarkbage]

Come to think of it, why isn't props already an argument to onUpdateComponent and onMountComponent? Wouldn't you need to get the props to build a debug tree for things like the Chrome devtools? Whatever API gets the props for a composite component could get them for the native component.

[gaearon]

Yeah, it should be an argument, I just didn’t have a use case yet in ReactPerf.

I was shooting for similar output as existing ReactPerf whose printOperations() print actual DOM work. Tracking new props is not quite equivalent. For example, update style currently only fires for changes individual values but if we were to fire events for any changed native props, the log would be spammed with update styles that have no effect on the render of every component containing them.

To make it useful, we would have to make the devtool aware of the fact that unlike any other native props, style itself needs to be shallowly unequal to the previous version, which mean we would have to keep it around and make the devtool aware of the special nature of style in the DOM renderer which doesn’t seem nice.

Spamming the log is not just bad because it becomes less useful. It is also bad because it makes printWasted() broken. If every style change is counted as a native operation, printWasted() will never consider components with inline styles wasted because they always seem to produce native operations. Maybe this isn’t the best heuristic but this is the single method people use the most and we can’t break it.

Indeed, native operations may change any day. This is actually exactly how this devtool is supposed to work. It reports whatever the renderer tells it, the names of everts are not set in stone. When DOM renderer changes to do things in a different way, it is free to fire different native operations in the places where it interfaces with the DOM to give the user a picture of what is going on.

[sebmarkbage]

printWasted could do an deepEqual test. One thing I wanted to try is never diffing native components, not store the previous props, and always override the native ones. Because the DOM calls in modern browsers now have little overhead and is effectively diffed inside the DOM anyway. The bulk of the work has already been done because lack of shouldComponentUpdate bailing out.

Basically when I turn that on, any of these assumptions in the tooling would immediately break and I'd have to go fix it.

I think there is a false assumption that DOM operations are heavy and therefore we overfocus on this level of the instrumentation. ReactPerf printing these operations is probably an artifact of that.

I'll accept for equivalence but I think we should change the heuristic and logged data to something more representative.

[gaearon]

I'll accept for equivalence but I think we should change the heuristic and logged data to something more representative.

👍

I filed it as #6632 and will come back to it after the old ReactPerf is gone.
For now let’s shoot for feature parity.