Automagic Custom Element transformorama#133
Conversation
Codecov Report
@@ Coverage Diff @@
## master #133 +/- ##
==========================================
+ Coverage 84.43% 84.82% +0.39%
==========================================
Files 38 39 +1
Lines 1593 1641 +48
Branches 389 407 +18
==========================================
+ Hits 1345 1392 +47
- Misses 248 249 +1
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #133 +/- ##
==========================================
+ Coverage 84.43% 85.01% +0.58%
==========================================
Files 38 39 +1
Lines 1593 1662 +69
Branches 389 414 +25
==========================================
+ Hits 1345 1413 +68
- Misses 248 249 +1
Continue to review full report at Codecov.
|
|
@rorticus small thought re the |
|
Yeah thats a good idea @matt-gadd. We could possibly pass in the package name as the default prefix, so it could be like |
|
Updated to set the |
Type: feature
The following has been addressed in the PR:
prettieras per the readme code style guidelinesDescription:
Working off of #98, refactored a bit to better align with our wants. This is really part 2 of what will be a 3 step process:
Supporting custom element decorator stackingApply decorator defaults inregisterCustomElementcli-build-widgetto apply this transformation.The general idea is that if you have a widget like this,
When targeted, it will automatically turn into:
The generated tag name is the name of the widget class, dashed on lower/uppercase boundaries, and lowercased. If the name has no dashes in it, it'll have
-widgetappended to the end so that it conforms to the custom element spec. SoHellobecomeshello-widget, andHelloWorldbecomeshello-world. The user will be able to override the tag name by manually applying a custom element decorator.Resolves #43