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:
>
> 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.
>
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
"Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/04aab05b-e5d0-4a26-a552-6474d7581aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
