Adds Ember.Debug.RenderDebug as an api for render debugging.

[teddyzeenny]

Currently exposes Ember.Debug.RenderDebug.getTopLevelNode which returns the top level inspected node.
InspectedNode is a wrapper class for the htmlbars render node. It provides public debugging methods
so that external tools like the Ember Inspector can use stable and tested apis.

I'm looking for feedback on this approach (mainly the InspectedNode class). cc @rwjblue @krisselden

[rwjblue]

We went with Ember.Debug for the deprecation log level implementation, can you swap to using that instead of Ember.Debugging?

[teddyzeenny]

Ember.Debug is probably going to conflict with the Ember Inspector's Ember.Debug. I can look into removing it from the inspector if you think it's worth it.

[mixonic]

@teddyzeenny oooomg namespaces :-/ Is is painful to rename in inspector? ember-debug-adapter?

[teddyzeenny]

I should be able to rename it - maybe to EmberInspector. Ember.Debug has always been a confusing name so it may be a good thing to rename it anyway.

[krisselden]

This is internal and should not be leaked, it should at least have an underscore prefix and not be documented like it is a thing.

[teddyzeenny]

The downside of making this inaccessible is that I can't match render nodes that I got from perf instrumentation to the render nodes in this view tree. (I use this to add render times next to the views in the view tree). Unless if we maybe provide the render node's guid here and in perf instrumentation?

[rwjblue]

@teddyzeenny - I'd love to land this. Can you rebase, fix the issues that @krisselden mentioned?

[teddyzeenny]

Updated.

[rwjblue]

I am happy with this. We can always iterate as we hit problems...

@krisselden - Are you ok with this as a first iteration?

[teddyzeenny]

@krisselden mentioned that the namespace Ember.Debug is something that should be removed from production builds, whereas inspection methods should not. So we would use something like Ember.Inspection instead. Downside is it adds another namespace to the Ember API. Thoughts?

[mmun]

@teddyzeenny I agree with that.

[rwjblue]

@teddyzeenny - Ember.Debug is not removed from production builds. The guts of our packages/ember-debug is not included, but the public API does exist (otherwise users calling functions on it would have broken apps only in prod).

[teddyzeenny]

@rwjblue I think @krisselden meant there's a difference in concept between debug and inspection and therefore should have separate namespaces. @krisselden can you confirm/deny?

I'd love to get this in as soon as possible so we can prevent more regressions to the view tree as Ember changes.

[rwjblue]

@teddyzeenny - Gotcha. Yeah, I'm fine with Ember.Inspection or some such. Should we move the current debug adapter there too?

[teddyzeenny]

@rwjblue yes it makes sense to move the data adapter but we should probably keep and deprecate the original Ember.DataAdapter since it was public api?

[rwjblue]

we should probably keep and deprecate the original

Yes, absolutely!

[homu]

☔ The latest upstream changes (presumably #12648) made this pull request unmergeable. Please resolve the merge conflicts.

[locks]

hey @teddyzeenny, is this still relevant?

[teddyzeenny]

Not relevant anymore. Closing.