Add support for web midi #234
Labels
Comments
|
Duplicate of #209 These were removed in 3f1285e#diff-7ce7b697c81d09379180b213c810f433c5f668e21c180651aa7876f48340669b when we planned on only supporting APIs that are supported by Chrome, Safari, and Firefox. #209 should add them back as these APIs are on the standards track and not experimental. |
srujzs
added a commit
to srujzs/web
that referenced
this issue
May 13, 2024
The current implementation only emits APIs that are on the standards track and supported in Chrome, Firefox, and Safari. This leaves out widely used APIs like Trusted Types, so this change relaxes those requirements. In order to support this change, a number of changes are included: - BrowserCompatData is modified to handle some slight discrepancies in how compatibility data is stored, including global APIs, namespaces, static members, and event handlers. - Interfaces and namespaces are generated based on whether they are standards track and experimental. If they are not generated, any references to them will be replaced by the equivalent JS type. - Likewise, inheritance for interfaces is modified to subtype the first generated interface in the inheritance hierarchy. - Dictionaries and typedef-like types are generated based on whether they are used as they don't have compatibility data. In order to determine this, whenever we generate a _RawType, we mark it as used, and recursively generate the types needed. - For each API within an interface, compat data in that interface and its superinterfaces are used to determine if an API is generated. - In order to support the above changes, intermediate representations for some members (attributes, fields, constants) are added. There are other members that might be worth moving to an IR, but that refactoring can be done in a future CL. Closes a number of issues: dart-lang#209 dart-lang#234 dart-lang#216 dart-lang#205 dart-lang#203 dart-lang#192
srujzs
added a commit
that referenced
this issue
May 21, 2024
* Only emit APIs that are standards track and not experimental The current implementation only emits APIs that are on the standards track and supported in Chrome, Firefox, and Safari. This leaves out widely used APIs like Trusted Types, so this change relaxes those requirements. In order to support this change, a number of changes are included: - BrowserCompatData is modified to handle some slight discrepancies in how compatibility data is stored, including global APIs, namespaces, static members, and event handlers. - Interfaces and namespaces are generated based on whether they are standards track and experimental. If they are not generated, any references to them will be replaced by the equivalent JS type. - Likewise, inheritance for interfaces is modified to subtype the first generated interface in the inheritance hierarchy. - Dictionaries and typedef-like types are generated based on whether they are used as they don't have compatibility data. In order to determine this, whenever we generate a _RawType, we mark it as used, and recursively generate the types needed. - For each API within an interface, compat data in that interface and its superinterfaces are used to determine if an API is generated. - In order to support the above changes, intermediate representations for some members (attributes, fields, constants) are added. There are other members that might be worth moving to an IR, but that refactoring can be done in a future CL. Closes a number of issues: #209 #234 #216 #205 #203 #192 * Generate APIs based on standards track and not experimental * Handle some TODOs that came up when addressing #209 - Removes an unnecessary null-check - Refactors getTypeForUnionCalculation to a shared _getJSTypeEquivalent function - Avoids shadowing an instance variable * Address some lints * Update CHANGELOG and README * Add types to the field declaration
|
Should be in the next major release now that #209 is closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the subject line says it all.
The text was updated successfully, but these errors were encountered: