[POC] Better debugging stack traces

[sophiebits]

I had an idea: what if our stack traces looked more like this so you don't just have 30 frames inside React and then a top-level render call, which is the typical situation nowadays?

Turns out we can do this with a small hack. Each time we create an element, we store away a function that just calls its argument:

var foo = React.createElementDebug(function element_Foo(x) { x(); }, Foo, ...);

then when we go to mount the component, we call this function with the mount code as argument so that it appears on the stack.

This is a little crazy and probably slow, but could make development nicer. You can't inspect the props (e.g., a, b, c here) but if we had the function capture those vars I think you could.

[sebmarkbage]

This is actually a really neat insight! __DEV__ mode is already super slow anyway (which is also a problem but a separate issue). I don't think this is necessarily making it much worse.

Another thing we were considering was using Promises so that the async debugging tools in Chrome would work.

Lets keep iterating on something like this.

[sebmarkbage]

@spicyj Here's a kind of related thought:

If you have a properly inferred name on the render function. E.g. ES6 classes would have a name like "MyComponent.render".

What if we in createElement did something like: new Error().stack and stored away the stack where it was created. That way you get not just where it was created, but also the indirect stack that got you there, including file/line which can be used by the devtools.

You could even use this to infer the "owner" name for use by debug outputs. That could allow us to avoid tracking owner even in debug mode.

[sophiebits]

Yes, we could. I assumed that would be much slower than this and not much more useful.

[sebmarkbage]

The benefits are that A) it works with unchanged syntax and any caller, not just JSX. B) it shows indirections. The downside is that you don't get the breakpoint debugger which is really neat.

[sophiebits]

cc @jaredly

[gaearon]

This is interesting but I’m not sure how feasible this would be perf-wise, or whether it would actually improve the situation rather than introduce more confusion.

Deep and seemingly unrelated stack traces are a real problem so let’s continue tracking it in #5460. I will close this PR, but we can revisit it later.

[jaredly]

Yeah I remember we had lots of discussions about this last year, but didn't come up with anything sufficiently performant.