search

globalizejs / globalize

A JavaScript library for internationalization and localization that leverages the official Unicode CLDR JSON data
https://globalizejs.com
MIT License
4.8k stars 605 forks source link

dateFormatter changed the behavior after the package version was updated #826

Closed dxvladislavvolkov closed 6 years ago

dxvladislavvolkov commented 6 years ago

I used to catch the error when I passed e.g. { day: 'numeric' } to the method. Now I get the function as the return value. Is it breaking change? or bug? You can see examples

  1. Globalize 1.1.1 (get error) http://plnkr.co/edit/wzRAJFW09PGhW8pr2Tne?p=preview

  2. Globalize 1.3.0 (get function) http://plnkr.co/edit/m1cYmQ7FWcrHbLKvJUyu?p=preview

rxaviers commented 6 years ago

There's no day option and it's therefore ignored. Please, check https://github.com/globalizejs/globalize/blob/master/doc/api/date/date-formatter.md

You should get a formatter with default options and I believe that's what you get. Otherwise, please let me know and I will reopen this bug.

dxvladislavvolkov commented 6 years ago

@rxaviers this is my problem. when I pass the wrong option, I get a formatter by default (although I expect an error, as it was before)

rxaviers commented 6 years ago

I've verified that on 1.1.1 we get an error like you mention:

Globalize('en').dateFormatter({foo: "bar"})
[object Object]: E_INVALID_PAR_VALUE: Invalid `{"name":"options","value":{"foo":"bar"}}` value (undefined).

But that was certainly a bug. Still on 1.1.1, other formatters don't behave like that.

Globalize('en').numberFormatter({foo:"bar"})
{ [Function: numberFormatter], ...}

On JavaScript, usually the kind of assertion you mention isn't performed, e.g.:

// Ignores foo: "bar" as well.
new Intl.DateTimeFormat('en', {foo: "bar"})
{}

Can you share a little more details on your use case? Why do you need that?