feat(types): add aria attributes and refactor type gen #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refactors the type generation logic found in the core package.
Key updates:
Aria attributes are now recognized and do not cause a type error ( resolves Allow aria attributes #2 ). Short term work still needs to be done to add JSDoc descriptions to each attribute, and refine their value type. Less short term, it would also be nice to restrict the allowed aria attributes to those that are compatible with the
role
of the element (is this possible?).Lerna mode was swapped to independent. This PR started out with the intention to move HTML types to their own package, and with that, I decided independent mode made a bit more sense for the repo. However, I changed my mind on splitting the types into a separate package due to some limitations with mapped types preserving JSDoc comments and tags. Ideally, I would like for more of the manual type generate to utilize TS itself over code gen, but at this point the IDE type hints are better if we are less DRY (sadly).
More investigation needs to be done on "convenience patterns", i.e. passing
Array<string>
as the value to.class()
. The behavior needs to be consistent--I think one off special cases are a potential footgun and I am removing for now ( concerns Type of class attribute allows array of strings #3 ). Should any of the convenience patterns be built in, or moved to a plugin? I am thinking plugins, but then, what is the best way for users to update the accepted types of theh
function?Prior art here, but it would involve changing the api in a way that requires constructing a new instance of
h
before it is usable:const h = new hdot()
.