Thanks! Yeah, something should be done about this. I'm wondering though whether it might be better to instead disallow attributes like b-c on nested components. There are definitely some other places in Svelte where property names that aren't valid as .whatever keys aren't supported.
I think once #1106 gets settled, we should do the same thing here.
I think there probably are more sweeping changes we want to make here. Data properties in components whose names aren't valid identifiers can't be accessed in template tags. It's true that get and set can still be manually used with them, but it seems worthwhile to have dev warnings if data() returns non-identifier-safe keys, or if set is called or the component constructor is called with invalid keys.
If we make those be dev warnings (and not dev exceptions), does it still make sense to disallow non-identifier-safe component arguments at compile time, or should that too be a warning and we just quote the key in the compiled component? Not sure what's best. How much limiting of the component author is helpful and how much is overbearing?
Additionally, a way to access these data fields from template tags could be added, though I can't think of a nice syntax.. {{this.get("b-c")}} seems overly verbose
My inclination here would be to disallow invalid identifiers as component properties, because there are so many caveats around their use (e.g. you can't use them in computed props, etc).
The one thing holding me back is the possibility of us introducing spread props, where leftover props could be added to an element:
<!-- App.html -->
<Widget data-foo='bar'/>
<!-- Widget.html -->
<div ...someSubsetOfProps>...</div>
Most helpful comment
My inclination here would be to disallow invalid identifiers as component properties, because there are so many caveats around their use (e.g. you can't use them in computed props, etc).
The one thing holding me back is the possibility of us introducing spread props, where leftover props could be added to an element: