You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Work can now be done to align svelte-retag's API to the new format in Svelte 4's <svelte:options customElement={…} /> (documented here). For example (copied from sveltejs/svelte#8681 (comment)):
Propose passing in the component as the first required parameter and then allow for an easy direct copy/paste of the Svelte 4 style customElement options as a second parameter (with the same baseline requirements). This will be supported features only.
Important: Rolling into v2 milestone., since this syntax should replace the old component definition syntax. Doing so should make the API of svelte-retag overall easier to comprehend for others (a huge plus for a library). Plus it’s likely easier to implement/maintain.
Supported features
Due to the complexity of the API (at time of writing) it may be worthwhile to outline exactly what we want as “must have” vs. “nice to have” if possible in this ticket. Otherwise, implement the “must haves” and delegate the “nice to have” features to a separate issue for now.
Must have
tag for tag name
shadow for use of shadow DOM or not (must default to true, methinks)
props where each key defines the property (e.g. greetName) with support for
attribute defines alternative attribute name
type to coerce to a particular type (instead of always being type String (per HTML attribute spec)
Nice to have
props where each key defines the property (e.g. greetName) with support for
Added explicit set of desired features in order of priority (must have vs. nice to have) to help explicitly call out desire to perform type coercion (as requested in #26 which is a dupe of this).
Quick note: Clarified that this will be for supported features only, i.e. either features that already exist or ones being added specifically in this ticket (e.g. custom attribute names and attribute type coercion).
This is worth calling out so that the expectation isn't set that we'll always 100% support all features of <svelte:options customElement={…} /> per se, but rather have an API that is very similar in order to support migration. This is not intended to be a drop-in but instead an alternative with the ability to enhance with additional features, where feasible. 🙂
patricknelson
changed the title
Move to Svelte 4 style custom element API
Move to Svelte 4 style custom element API, support prop type coercion
Dec 4, 2023
Svelte 4.0.0 has been released: https://svelte.dev/blog/svelte-4.
Work can now be done to align
svelte-retag
's API to the new format in Svelte 4's<svelte:options customElement={…} />
(documented here). For example (copied from sveltejs/svelte#8681 (comment)):Propose passing in the component as the first required parameter and then allow for an easy direct copy/paste of the Svelte 4 style
customElement
options as a second parameter (with the same baseline requirements). This will be supported features only.Important: Rolling into v2 milestone., since this syntax should replace the old component definition syntax. Doing so should make the API of
svelte-retag
overall easier to comprehend for others (a huge plus for a library). Plus it’s likely easier to implement/maintain.Supported features
Due to the complexity of the API (at time of writing) it may be worthwhile to outline exactly what we want as “must have” vs. “nice to have” if possible in this ticket. Otherwise, implement the “must haves” and delegate the “nice to have” features to a separate issue for now.
Must have
tag
for tag nameshadow
for use of shadow DOM or not (must default totrue
, methinks)props
where each key defines the property (e.g.greetName
) with support forattribute
defines alternative attribute nametype
to coerce to a particular type (instead of always being typeString
(per HTML attribute spec)Nice to have
props
where each key defines the property (e.g.greetName
) with support forreflect
to perform the inverse of the current reactive forwarding, i.e. watch for changes in the component and forward that to the attribute in the DOM. See Add ability to reflect prop changes back to attributes #43extend
add ability to pass main class constructor to provided callback so it can extend and then return the class to instantiate for the maincustomElements.define()
call. See Add "extend" option to enable ability to use own custom element class #42The text was updated successfully, but these errors were encountered: