intlFormat: use single combined options parameter #3807
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.
The current implementation of intlFormat currently supports three different call signatures for providing options: calling with format options, calling with locale options, or calling with both as separate arguments.
When the newer intlFormatDistance was implemented, it used a much simpler call signature, with all options bundled into one parameter.
Having different paradigms for the two functions seems odd, and so this proposal would change the canonical signature for passing options to intlFormat to
where IntlFormatOptions accepts both DateTimeFormat options and the locale property.
This signature is already compatible with both of the old two-parameter signatures, and so just replaces them. The old three-parameter call signature would be deprecated, but remain supported for the time being.
This PR contains a supplementary change to add options destructuring to intlFormatDistance, in the same way that it's used in this update to intlFormat. The current implementation of intlFormatDistance from #3796 doesn't remove the locales and unit properties from the options argument before passing it to Intl.RelativeTimeFormat; although these are ignored by the constructor, it's probably best practice not to include cruft with the passed RelativeTimeFormat options.