Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

casual pollutes the global momentjs instance with Norwegian locale #77

Open
dan-weaver opened this issue Nov 22, 2017 · 2 comments
Open

Comments

@dan-weaver
Copy link

dan-weaver commented Nov 22, 2017

Looks like when we import casual in our test framework it alters the global moment 's locale setting. All our modules under tests then decide to humanize dates in norwegian instead of english (the default). Should casual use "instance level" locale methods as described here: https://github.com/moment/momentjs.com/blob/master/docs/moment/06-i18n/02-instance-locale.md

I'm happy to submit a PR if someone can confirm this what should be done.. Looks like a small set of changes needed:
https://github.com/boo1ean/casual/search?utf8=%E2%9C%93&q=moment&type=

casual-moment

@dan-weaver dan-weaver changed the title casual pollutes the global momentjs instance with norwegian locale casual pollutes the global momentjs instance with Norwegian locale Nov 22, 2017
@dan-weaver
Copy link
Author

Oops I appologize.. This may only be a casual-browserify bug.. i thought casual-browserify depended on casual.. If that's not the case I can move this issue?

@darrensapalo
Copy link

darrensapalo commented May 17, 2019

I'm still encountering this problem as well, on using casual-browserify. Is the repo owner open to pull-requests for this issue?

Search on GitHub forks do not work. This error still persists on the casual-browserify branch as seen here.

I agree that the locale should be set at an instance level. The scope for the variable I think can either be:

  1. Stored on the provider object scope (pros: we cache it instead of reproducing it again and again each time we need to format something; cons: we consume memory on the provider) or

  2. we just construct a new moment() each time we need to format the date (pros: no memory held for the moment instance; cons: we need to construct an object each time a date is generated).

I am not certain which is the wiser decision. Seeing as this is a fake data generator, choice 2 scales the more fake data (of type date) is created, while choice 1 is limited to the number of providers (constant 15). Given that, I'd go for choice 1 instead.

Interested to hear anyone's thoughts on this.

I started with the changes here but am unsure how to proceed with changing the usages of the providers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants