Skip to content

Conversation

@FourwingsY
Copy link
Contributor

Please fill in this template.

  • Use a meaningful title for the pull request. Include the name of the package modified.
  • Test the change in your own code. (Compile and run.)
  • Follow the advice from the readme.
  • Avoid common mistakes.
  • Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

  • Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/moment/luxon/tree/master/src
  • Increase the version number in the header if appropriate.
  • If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }.

static defaultLocale: string;
static defaultNumberingSystem: string;
static defaultOutputCalendar: string;
static defaultZone: Zone;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah, I just saw this PR after I submitted one fixing the Settings. See #22494.

I defined it as a namespace to avoid the linting error preventing classes having only static methods, but I'm not sure this rule is a good one, especially since it forced me to define defaultZone as a const, although it's actually a read-only property.

This should be fixed here, as there is no setter for defaultZone in the JS code: see https://github.com/moment/luxon/blob/master/src/settings.js#L52

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am thinking on this problem. How do you think about this?

class Settings {
  static readonly defaultZone: Zone;
}

Yes, I'm not sure too. about disabling lint rules is not the good way or not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a class is closer to how the JS code is actually designed, and a readonly property is closer to the reality than a const variable. That's how I originally designed Settings in my PR, but the linter shouted at me, and I didn't want to take the responsibility of removing the linting rule, not being the original author of the typing. But I personally don't have a problem with removing it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove my PR, BTW, since this one solves the problem I wanted to solve.

static defaultZone: Zone;
static defaultZoneName: string;
static throwOnInvalid: boolean;
static now(): number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now is a property, with a getter and a setter. See https://github.com/moment/luxon/blob/master/src/settings.js#L20. It should be defined as

static now: number;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now is a callback for returning the current timestamp, so it should be a function. on default, now has defined in https://github.com/moment/luxon/blob/master/src/settings.js#L5
so it should be like static now: () => number
and i have a question. is this different with static now(): number?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're absolutely right, I misread the code. I'm not a specialist, but as I see it designed on the JS code, I think using

static now: () => number

would be clearer. It show that now is just a readable/writable property of type function that is meant to be replaced by another one, and not a static method of the class.

@jnizet jnizet mentioned this pull request Dec 24, 2017
7 tasks
jnizet added a commit to Ninja-Squad/globe42 that referenced this pull request Dec 24, 2017
Since they're all new, they have a bug, that I fixed by using our own typings, copied from a PR that fiexes them. See DefinitelyTyped/DefinitelyTyped#22463
make Settings.defaultZone as readonly,
change expression of Settings.now
jnizet added a commit to Ninja-Squad/globe42 that referenced this pull request Dec 27, 2017
Advantages:
 - cleaner immutable API
 - shorter bundle (-50KB from the gzipped bundle)

Drawbacks:
 - not stable yet
 - no built-in formatting of durations

Since typings are all new, they have a bug, that I fixed by using our own typings, copied from a PR that fiexes them. See DefinitelyTyped/DefinitelyTyped#22463
@typescript-bot
Copy link
Contributor

🔔 @jnizet - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

@typescript-bot
Copy link
Contributor

We've gotten sign-off from a reviewer 👏. A maintainer will soon review this PR and merge it if there are no issues. If it shouldn't be merged yet, please leave a comment saying so and we'll wait. Thank you for contributing to DefinitelyTyped!

@typescript-bot typescript-bot added Other Approved This PR was reviewed and signed-off by a community member. Merge:LGTM labels Dec 27, 2017
throwOnInvalid: boolean;
resetCache(): void;
};
class Settings {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WHy did you make this a class, and add a rule in the tslint.config?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lint rules saids Every member of this class is static. Use namespaces or plain objects instead.
For test, it should be namespace, not the type or interface.
But I thought the luxon code is written in class, so class seems to be right. Even there is rare possibility for Settings or Info class will be changed for having instance methods.

How do you think? namespace is more clearer than class with static?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, namespace is probably better, if/when an instance method is added we can make additional changes then.

@typescript-bot typescript-bot added Revision needed This PR needs code changes before it can be merged. and removed Other Approved This PR was reviewed and signed-off by a community member. labels Dec 27, 2017
@typescript-bot
Copy link
Contributor

@FourwingsY One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits. Thank you!

@FourwingsY
Copy link
Contributor Author

@paulvanbrenk yup i changed to namespaces, and removed lint rule.

@typescript-bot
Copy link
Contributor

🔔 @paulvanbrenk - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

@typescript-bot typescript-bot removed the Revision needed This PR needs code changes before it can be merged. label Dec 30, 2017
@jan-swiecki
Copy link

@FourwingsY thanks for this, DateObjectUnits.month didn't work and I found your fix :). Waiting for merge:)

@mhegazy mhegazy merged commit a61e766 into DefinitelyTyped:master Jan 3, 2018
@zerosym
Copy link

zerosym commented Jan 11, 2018

Just a heads up, there's a small typo here:
a61e766#diff-1c925493760f8ad902b55a86386e0bd5R66

Missing the letter 'T' for DATETIME_HUGE & DATETIME_HUGE_WITH_SECONDS

@jnizet
Copy link
Contributor

jnizet commented Jan 13, 2018

@zerosym I made the change in #22877

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

Successfully merging this pull request may close these issues.

7 participants