Closed zdenko closed 5 years ago
There are a few things I'd like to discuss.
To start with, if your component is called custom-tag-name
you just define it as CustomTagName
, there's no need to add an extra naming property, since name
and tagName
are already part of the object literal/class based API.
On top of that, Custom<custom-tag-name>
as definition string should already do what you want.
Agreed that the -heresy
suffix to grant zero conflicts with other custom elements libraries might be a bummer for custom elements migrations, so I don't mind that part, but it needs to be implemented in an efficient way that is not through RegExp match.
Are you OK with the current state, if -heresy
suffix goes away, when not needed, and you can still define your component names via curent mechanism, which should work already?
Custom<custom-tag-name>
as definition string
Oh, I missed that.
This is indeed sufficient and covers all cases where CustomTagName
might not be possible to use.
👍
Please note while I thought it would've worked, it actually didn't, so I'm patching as we speak the implementation to properly default to element
and let you define Custom<any-tag>
.
Fixed in v0.14
.
Please do open an issue next time, instead of submitting directly a MR, so we can talk a bit before going implementation ;-)
Thanks 👋
This PR implements option to avoid adding the word "-heresy" to the element name in case it is already hyphened. Additionally, a property
elementName
(optional) which contains a custom element name is added to the API. Example:I'm evaluating "heresy" for use in our project in which there are already custom elements, and their names can't be changed. Since heresy automatically adds the word "-heresy" to every element, this presents an obstacle, and with this PR, I wanted to find a way to overcome it.