Allow hyphenated properties to be defined in a component

[ahopkins]

Is your feature request related to a problem? Please describe.

Given the usage of the following hypothetical component:

<Icon data-tooltip="foobar" />

I receive a warning that data-tooltip has not been declared as a property on the Icon component. However, there is no way to do that since it is hyphenated.

Describe the solution you'd like

Inside my component, it would be nice if I could declare the property like this:

export let dataTooltip = null

Describe alternatives you've considered

I know that the properties are also available in $$props. But that doesn't really solve the problem.

const dataTooltip = $$props['data-tooltip']

While this would give me access to the value, it doesn't remove the in browser warning.

How important is this feature to you?

It's annoying. Important? Well, certainly not a deal killer. And for now I just am using the form: <Icon tooltip="foobar" />. And then I am passing the property to the hyphenated version inside the component.

The reason this came about was I was trying to just use a spread operator and pass props thru. But, here I cannot because I don't want to keep seeing those warnings all over the place.

[Conduitry]

A component's 'unknown prop' warning is supposed to be suppressed if the component uses $$props at all (#2881). Is this not what you're seeing? Do you have a repro?

[ahopkins]

Thanks for the response. I believe that I was still getting it, but I'll go back and post a snippet when I get back to a computer.

In this specific case, the property looks like HTML5 user-defined data.

Maybe take hyphenated names and make the second word of the hyphen a key inside the first name?

Such as:

<Foo data-test="some data">
//... inside Foo
<script>
export let data;
</script>
{data.test}

[ahopkins]

True, but I am not sure that would be the only use case.

[antony]

@dkondrad @ahopkins yeah I think this is a bad example. Ignoring data- prefixes, something as simple as:

<Profile avatarType="xxx">

where I'd really prefer to declare it as:

<Profile avatar-type="xxx">

[ahopkins]

@antony I agree. It just so happened that my example I was using something that required a data- property.

I agree with your example.

[Conduitry]

@ahopkins Did you ever get a reproduction for the 'unknown prop' warning persisting despite the component referencing $$props?

[ahopkins]

Of course I cannot recreate it now ...

myCredibility -= 1

As stated, as soon as $$props is referenced, the warning goes away. Perhaps I had this on an older build of svelte?

[ahopkins]

@Conduitry I am not sure that this was ready to be closed. The warning was sort of a side matter.

I think the issue (as displayed by @antony) is still a valid feature request. Unless you are saying this is not something that you would entertain?

[Conduitry]

Yeah, fair, we can re-open this.

[antony]

This needs to be done before Rich comes along and does this:

<Profile avatar_type="xxx">

But seriously... not sure what the behaviour should be if we did this:

<Profile avatarType="xxx"  avatar-type="xxx">

export let avatarType

I suppose we could consider avatar-type to be equivalent to avatarType and thus act as if the same prop had been declared twice, which is currently to throw an error saying "Attributes need to be unique (5:18)" - perhaps this message needs to say something like "Attributes need to be unique, excluding hyphens" or something far more meaningful than that.

Another weird edge case:

<Profile avatar--type="xxx">

I'd suggest that the above is left intact, thus ending up as the (un-addressable) prop avatar--type.