Update Intl.DisplayNames types for better spec compliance#48442
Merged
sandersn merged 4 commits intomicrosoft:mainfrom Apr 5, 2022
Merged
Update Intl.DisplayNames types for better spec compliance#48442sandersn merged 4 commits intomicrosoft:mainfrom
sandersn merged 4 commits intomicrosoft:mainfrom
Conversation
Collaborator
|
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
sandersn
approved these changes
Apr 5, 2022
Member
sandersn
left a comment
There was a problem hiding this comment.
I think it's fine to take this change as-is and follow up on ResolvedDisplayNamesType during the beta.
| | "code" | ||
| | "none"; | ||
|
|
||
| type ResolvedDisplayNamesType = |
Member
There was a problem hiding this comment.
Will there be anybody using ResolvedDisplayNamesType? If so, it should stick around around as a simple alias of DisplayNamesType
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Following up on issue #48218 (to avoid creating too many issues about the same topic) and based on the work from pr #48262 , here are some additional updates to keep
Intl.DisplayNamesup-to-date with the spec:ResolvedDisplayNamesOptions.typeshould be the same type asDisplayNamesOptions.type, because DisplayName's internal type property simply gets mapped toresolvedOptions().type.DisplayNamesOptions.languageDisplay,resolvedOptions()can also have the propertylanguageDisplay, but only whenDisplayNamesOptions.typeis of typelanguage.Intl.DisplayNames(locales, options)constructor requires bothlocalesandoptions.type, althoughlocalescan be undefined.localesparam inIntl.DisplayNames(locales, options)andIntl.DisplayNames.supportedLocalesOf(locales)is the sameLocalesArgumenttype used across other functions fromIntl. Additionally,LocalesArgumentdoesn't strictly need to be an array of solely strings or an array of solely Locale(s), it can be an array containing both.localesargument are defined to be processed with this same operation.locales,options, andoptions.localeMatcherare optional inIntl.DisplayNames.supportedLocalesOf(locales, options).These behaviors have been verified with the js code below, which should execute without issue (lines meant to recreate a
TypeErrorhave been commented, and can be uncommented for testing):The code above should behave as expected on modern browsers, tested on Chrome(99.0.4844.84) and Firefox(98.0.2). The only caveat is that
"calendar","dateTimeField", andlanguageDisplayare features introduced ines2022from this proposal, so those are currently not working in the latest NodeJs LTS v16.14.2, but should work in later versions (currently working on v17.8.0).