Add typings for ARIA attributes #3910
Conversation
src/jsx.d.ts
Outdated
| | 'tree' | ||
| | 'treegrid' | ||
| | 'treeitem' | ||
| | (string & {}); // This trick allows any string to be valid here but also provides TS auto-complete behavior for the explicitly listed values here |
There was a problem hiding this comment.
What's the reason for allowing any string to be valid? Are there use cases for using roles outside of this list? Genuinely curious.
There was a problem hiding this comment.
Tbh, I'm not entirely sure. I've copied this from React. I assume it's to accommodate new roles as the spec changes? I need to check the git history of their types to see the reasoning.
There was a problem hiding this comment.
I couldn't think of a reason and went back through the aria spec and didn't find anything concrete there either.
The spec doesn't change very quickly (last version was published December 2017) so having that carve out doesn't seem too pressing IMO. (That said, ARIA 1.2 should be published soon but it's also been soon for like a year now... But that still a 6 year cadence if it gets published this year.) It's also kind of a slippery slope where you could argue any of the attributes should allow for anything because the spec could change.
There was a problem hiding this comment.
Ah, sorry, missed that. Doesn't look like a reason was given, unless I'm missing part of the conversation.
I'm admittedly not a TS maximalist, so I personally have no issue with a string fallback (working auto-complete is lovely enough), but I wonder if it's better to be strict and maybe catch some typos, even if that means we might need to make alterations in the future? I'm not super knowledgeable about aria stuff though, so maybe there is a use for other roles.
There was a problem hiding this comment.
@myasonik Yea, that makes sense. No point to reduce the usefulness of these typings just cuz anything could change lol. And like you said, the churn is super infrequent.
Thanks for digging that link up @rschristian! I dug a little further and it looks like this was the original thinking (link):
- It should still allow unknown roles e.g. when new roles are added but types are outdated
- what about fallback roles e.g. role="none presentation"?
For 1, like @myasonik was saying, I'm not worried about it anymore. But the second reason is news to me. I've never heard of "fallback roles" before. Scanning the spec, I can only find one reference to fallbacks roles in a note.
Maybe to start off we can just manually add "none presentation" as a possible role value? And in the future deal with other fallback roles as changes to the spec land? At that time we can either manually add more fallback combinations or look at more advanced TS techniques if it becomes complicated.
There was a problem hiding this comment.
I went with adding 'none presentation' and removing (string & {}) for now as that's my vote, but would like to hear what others think as well before merging.
There was a problem hiding this comment.
Ah, I forgot about that and missed it when going back through... It's pretty uncommon but, yeah, role takes a space separated list of roles that you can use as fallbacks (https://www.w3.org/TR/wai-aria-1.1/#host_general_role)
The none presentation example given in the spec was there because none was new at the time so presentation was an appropriate fallback. But you can theoretically do it with any combination at any arbitrary length.
Though I can't imagine this being used very often, I do think allowing everything the spec allows is probably important enough to allow (string & {}) even if we agree that 'future-proofing' isn't worthwhile.
Related: #3853