Up to now, we've been copying Moment's forward-looking locale API.
That Moment API has a setter and getter for a global locale setting. These can be used to change the behavior of the parsing functions at any time, and Moment instances can be bound to this global setting so that their locale changes whenever the global setting changes.
Thing is, the very idea of having global state that's changeable at runtime is a very poor fit for a library where immutability is the primary selling point. As a result, we will be sharply curtailing the scope of FrozenMoment's global locale setting.
Our revised API will focus on enabling developers to configure a non-English default locale for all new FrozenMoments created in a particular runtime environment. (A runtime environment is a web page in the browser, or a Node application.) Applications that need to change locales at runtime should always set the locale on their FrozenMoment instances, and/or override each instance's locale setting for each formatting operation.
Here's a minimal set of required API changes:
[ ] Refuse to set the global locale with frozenMoment.locale() after instantiating an object using that setting (whether a FrozenMoment, a Duration, or a builder for either type). Complain loudly in the console logs when the setter fails for this reason.
[ ] Return a truthy value from the global locale setter when it succeeds and a falsy value when it fails. (That success value should probably the key of the newly selected global locale, because we can set with an array of locales and we may also coerce the provided value to a more general locale key.)
[ ] Since we're breaking API compatibility with Moment, rename the global locale setter to frozenMoment.setDefaultLocale() (or something similarly appropriate).
[ ] Remove the getter for the global locale -- but let's keep the global localeData getter, at least for now.
[ ] Update the documentation to reflect these API changes.
(This follows up on observations from PR #9, as part of my continued work on issue #2.)
Up to now, we've been copying Moment's forward-looking locale API.
That Moment API has a setter and getter for a global locale setting. These can be used to change the behavior of the parsing functions at any time, and Moment instances can be bound to this global setting so that their locale changes whenever the global setting changes.
Thing is, the very idea of having global state that's changeable at runtime is a very poor fit for a library where immutability is the primary selling point. As a result, we will be sharply curtailing the scope of FrozenMoment's global locale setting.
Our revised API will focus on enabling developers to configure a non-English default locale for all new FrozenMoments created in a particular runtime environment. (A runtime environment is a web page in the browser, or a Node application.) Applications that need to change locales at runtime should always set the locale on their FrozenMoment instances, and/or override each instance's locale setting for each formatting operation.
Here's a minimal set of required API changes:
frozenMoment.locale()after instantiating an object using that setting (whether a FrozenMoment, a Duration, or a builder for either type). Complain loudly in the console logs when the setter fails for this reason.frozenMoment.setDefaultLocale()(or something similarly appropriate).(This follows up on observations from PR #9, as part of my continued work on issue #2.)