Allow exporting DOM elements to the Console

[jasta]

This assigns the special variable $0 to match the selection in the
Elements tab.

[rickbrew]

we should probably talk with @ichub about this. In his refactoring PR #237 we are splitting DOM into two classes, DOM and Document, with the intent that CSS will have a reference to Document in order to avoid having a reference to DOM. In this case you're giving Console access to DOM and Runtime and that may not be the right approach, especially since you don't actually need DOM -- you need the ObjectIdMapper.

[jasta]

I'm giving them access because this is a public API contract and I don't want to be discrete about what is needed for fear of having frequent and possibly confusing changes to the API. There are solutions of course, but we should consider public API surface area and the fact that this is currently our only "configuration" mechanism we offer.

[rickbrew]

So now the dependency from Console to DOM and Runtime is part of the public contract? You say you want to avoid frequent and possibly confusing changes to the API, but I think that's precisely what you're introducing here. Why do I need to create DOM and Runtime and then plug those into Console? What happens when we change our mind and Console no longer needs either of these? Do I need to supply the same DOM to Console that I already plugged into a call to modules.add(), or should I add a new one? This all sounds pretty confusing and arbitrary to me.

I think it'd be better to handle this internally somehow. For example, DescriptorMap does initialization of Descriptors in 2 phases. First you register Descriptors, and then in phase 2 they all get linked together by Descriptormap.

So maybe ChromeDevtoolsDomain could have two new methods, Class<?>[] getDependencies() and void provideDependency(Class<?>, Object). Console's implementation of getDependencies would return { DOM.class, Runtime.class } and be given the appropriate stuff via multiple calls to provideDependency when we build().

It's hardly a wonderful or elegant solution but it keeps this dependency management as an internal Stetho problem.

[facebook-github-bot]

Thank you for your pull request. We require contributors to sign our Contributor License Agreement, and yours has expired.

Before we can review or merge your code, we need you to email [email protected] with your details so we can update your status.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!