Improvement suggestion for Chrome Dev Tool Support

[Bruce Anderson]

It's nice that Chrome dev tools provides some support already for debugging custom elements, i.e. being able to inspect an element, then click on the containing  custom element, and opening the properties tab.

But the support is quite klunky compared to what the React chrome extension provides -- in particular color coding in sharp red where the React component containers are, and with a single click, seeing all the property values of the element.

Are there immediate plans to similarly enhance the chrome dev tools for native custom elements?   Any ETA?  Or, alternatively, a chrome extension like React's?

I'm not sure if the React extension supports this, but one additional feature that would be really beneficial, is if, in the window where you can inspect the properties / methods defined for a particular custom element instance, one could add a break point to any of the methods (on entry), only for that instance of the selected custom element, especially if it could persist on refreshing the page, just like breakpoints in the javascript source.

Would be great to know either way what the plans are. Apologies if I missed it being announced in the Polymer Summit, or if this already exists and I'm not aware of it.

[Bruce Anderson]

More suggestions:

In the properties tab, it appears to list the inheritance hierarchy leading up to the custom element, including mixins.  That's great.  But there are many rows that show "HTMLElement" at the top level.  It would be much better if it showed the name of the constructor instead where applicable, so it is easy to find the layer you are looking for.

I think the top level node should show the object fully merged together, including the methods.  For some reason, the methods only show if I go one level down to the top most "HTMLElement."  

And I'll add my Trumpian "lots of people want" the ability to add a breakpoint in a method just for that particular instance of a custom element.  Okay, "lots of people" is a colleague I work with, and me.  Is there an easy programmatic trick to get this to happen?

[Bruce Anderson]

In case anyone is wondering (and at the risk of stating the obvious to everyone but me), it is possible to add a breakpoint to one specific instance of a method of a web component thusly:

• Right click and inspect element inside the custom element you want to debug
• Find the containing containing custom element, using #shadow-root nodes (if applicable) and dashed tag names as your clues
• Right-click on the containing custom element and select Copy => Copy Selector
• Go to the properties tab and select the second node that has the methods associated with the custom element.  Unfortunately, it is labeled "HTMLElement" rather than the more self-explanatory constructor property
• Find the method towards the end, in faint lettering
• Right click on the method and select Show Function Definition
• Within the function, right click where you want to put the breakpoint and select "Add conditional breakpoint..."
• In your conditional breakpoint editor, put:   this.matches('[paste selector from above]')

I still think it would be useful to provide a way to do this in fewer steps, but that's just me.

[Bruce Anderson]

I've been documenting, for my workplace, the steps for how to debug web components.  A quick search of the web for where this might be spelled out comes up short.   If you know of such documentation, please let me know.

It's surprising, because as I go through it, I think this may be one of the most important benefits of  web components.  The mental connection one can make by being able to physically connect a UI element you see on the screen, to the class definition behind it, is such a time saver, the saved person hours in the world economy could easily fund researching and developing 100 new Oreo cookies per year :-).  It reminds me of how revolutionary  "View Source" was to application development so many years ago.

So I'm kind of reiterating points already made here.  But in order of importance, these improvements (in my mind) would really spruce up my documentation.

• Properties Tab
• Show the class name (which you can get by viewing  the constructor property), rather than "HTML Element"
• Be able to right click on the class name above, and jump to the class definition in the code, rather than having to scroll down to the constructor property.
• Put all the light font properties at the top, rather than at the bottom.  These seem to be the properties developers will be most interested in.
• I can't quite figure out what the intended purpose of showing a separate item at the top, that shows the tag, independent of the class behind the component.  But what I noticed is that, for the other HTMLElement items, the light font properties change at each level, effectively hiding implementations that go deeper down.  I like that, because it makes each layer seem less overwhelming.  On the other hand, it makes me wonder why the solid font properties need to be repeatedly listed at each level?  So the top level node might be a useful addition if it combined all those properties / methods together so you get the full picture.  The only downside is this would be the first thing a developer would open, and it might be overwhelming.  Unless maybe they were lured to the second node by seeing the name of their beloved class they developed.
• The source tree
• Finding the containing custom element isn't too bad -- looking for a tag with a dash, typically followed by #shadow-root is fairly straightforward.  On the other hand, many non-web component frameworks like Angular or Aurelia also used dashed tag names.  Some of those might be combined with adding a shadow dom root.  And some custom elements might not use Shadow DOM, like AMP.  So I think it is appropriate to mark those elements that are true custom elements in a special way.  I'm thinking the gear emoji?  ⚙️Maybe mark all the other dashed-tag dom elements that aren't custom elements with the poop emoji?  :-)
• Be able to left click on the gear emoji.  This would open the properties tab, and expand the second level item, so you can quickly see your properties (at the top!) with a single click / no scrolling.  
• Be able to right click on the gear emoji, and jump to the class definition behind the component.  From there you could right click on a line and get a new option "Add context based breakpoint" that would insert a conditional breakpoint, with the css path uniquely identifying the node from which the gear emoji was clicked.
• Clicking on the poop emoji would emit a sighing noise, or worse :-) .

On Tuesday, March 7, 2017 at 5:43:38 PM UTC-5, Bruce Anderson wrote: