glint
glint copied to clipboard
typed-ember
provide suggestions and type checking for elements attributes
this would also make it possible to wrap WebComponents and have auto completions and type checking for those.
also allows any key. ideally we should only allow any key, if its prefixed with data-.
unfortunately <WebComponent myoptions="<cursor here>" /> does not provide completions.
But <WebComponent myoptions={{"<cursor here>"}} /> does
hmmm, this needs a way to distinguish exactly between svg elements and html elements...
would need to add a parameter to emitElement when in svg context
Thanks for this, but I think this is conflating HTML attributes and DOM properties in a way that doesn't quite work.
The properties on an Element subtype aren't the same as the attributes it accepts. Some attributes and properties do align 1-to-1, like id, but many either don't directly align, like data-* attributes that correspond to dataset.* properties, or only exist on one side or the other, like aria-* attributes or the textContent property.
If we can't get a list of attributes, surely it would be better to have some completion rather than the none-situation we have today. We could filter out DOM properties that aren't single-words, so at least the single-word attribute / dom properties match up. That's an improvement.
does TS provide no map/list of attributes?
We spent time looking into this earlier on in Glint's development—I think everyone involved agrees this would be nice to have! TS doesn't include anything like this in its standard library, though, and at least as of when we last checked we didn't find any third-party version either.
what about this? npmjs.com/package/html-element-attributes
At a types level, that just exposes Record<string, Array<string>>:
https://github.com/wooorm/html-element-attributes/blob/main/build.js#L88
We could filter out DOM properties that aren't single-words, so at least the single-word attribute / dom properties match up.
Is that a valid heuristic? I feel pretty strongly that wrong completions are worse than no completions.
I feel pretty strongly that wrong completions are worse than no completions.
yes, but a subset of incomplete, yet correct completions are better than no completions.
At a types level, that just exposes Record<string, Array
>:
we could PR them to as const that whole structure (and sub structure) in index.js, which would make the type more specific.
I like this.
yes, but a subset of incomplete, yet correct completions are better than no completions.
Yes, which is exactly why I asked if your suggested heuristic of only doing single-word ones actually works 😜
In other words, my point is that this isn't just a casing issue. Driving off of Element properties would include, for instance, dataset as a suggestion, which isn't a valid HTML attribute. I don't think we have evidence that even just single-word names have any guarantee of aligning across the attribute/property line.
I think making a pr to https://www.npmjs.com/package/html-element-attributes to generate a d.ts would then make ut usable
Let's see what the maintainer says: https://github.com/wooorm/html-element-attributes/issues/9
I've worked with them before with remark/unified/codemirror stuff before, and iirc, they're pretty responsive.
well, I couldn't give up just yet :) i build an own element.d.ts based on various packages from woorm. its all interfaces, so it should be possible to augment them with custom definitions.
now i only get valid completions for element attributes. unfortunately it only works inside an AttrNode
so <a h$cursor$ ></a>
if we had a node for the tag name, we could probably default the location to attributes for the rest