Route a debug path (parent node path) for use in debugging messages. Use it in one of the warnings

[jimfb]

Route a debug path (parent node path) for use in debugging messages. Use it in one of the warnings (more to come in the next couple PRs - in particular, the future PR that will solve #140 for us).

[jimfb]

@spicyj @sebmarkbage Ping.

[jimfb]

@spicyj @sebmarkbage Ping.

[sebmarkbage]

We should pass a pointer. This won't work with re parenting and windowing reuse.

[jimfb]

Ok, updated to use pointers to debug path nodes, which should be easier to update if/when we implement reparenting/windowing. @sebmarkbage @spicyj

[facebook-github-bot]

@jimfb updated the pull request.

[jimfb]

Ping @sebmarkbage @spicyj

[sophiebits]

Why not just store a pointer to the parent? This seems unnecessarily complicated.

Also, when is the parent path significantly more useful? I had developed something like this originally for the DOM nesting warning and @sebmarkbage convinced me that the owner list is equally useful.

[jimfb]

@spicyj The parent path is most useful when you have a single component that renders to non-trivial markup, and it becomes difficult to figure out exactly which element is firing. Ideally I would give line numbers, but the full parent path is the next best thing.

[sophiebits]

Maybe we should make line numbers instead then, like #4596.

[jimfb]

I agree, but that's a whole other can of worms. As of today, we don't have line number information and we do have parent information. Once source information is available (ie. we figure out a story around source information, we update the transpilers, etc), I'm happy to help migrate this to line numbers. In the mean time, this is a valuable bit of contextual information that we can provide.

Even if we had line numbers relatively well supported, that relies on the transformer whereas parents are valuable even if you are writing your ReactDOM.createElements by hand.

Anyway, I don't think that should block this diff.

[jimfb]

Replaced by new devtools API.