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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move from moment to native Date object backed with date-fns #1580

Merged
merged 29 commits into from
Jun 22, 2021

Conversation

paroxp
Copy link
Member

@paroxp paroxp commented Jun 22, 2021

What

moment is EOL. We should be moving off it.

moment, although has served its purpose, has been somewhat opinionated and specific, which caused our codebase to purely rely on moment.Moment and moment.Duration types. This makes it difficult to move off, upgrade or maintain the code.

We've had a chat, and decided that native Date, should be preferably used throughout the codebase, to maintain the simplicity and potential for us to migrate/maintain when necessary.

I've started off, with writing few simple functions, such as format, add, subtract, duration - just to make the usage of Date a little simpler. But that list started to expand slowly and realistically... has been solved elsewhere. So instead of wasting time, I took a smaller steps and the time, and opted in for date-fns. Fell in love on the way.

As part of this, while manually having to change the usage of moment, my eyes were hurt by some linting highlights, so I've fixed them on the way.

How to review

  • Sanity check
  • Code review
  • Have a look around a running instance (specifically around metrics please)

馃毃鈿狅笍 Please do not merge this pull request via the GitHub UI 鈿狅笍馃毃

@kr8n3r
Copy link
Contributor

kr8n3r commented Jun 22, 2021

service metrics filter range on first view (last 24 hours):

  • end date should be today, but it's today - 1
  • Each point on a graph is aggregated over 300 seconds of data, whereas on prod we convert that to 5 minutes (minor thing i reckon)
  • not sure if I can trust the graph start point (issue with stub data?)

Screenshot 2021-06-22 at 10 50 12

@paroxp paroxp force-pushed the move-from-momentjs-to-datefs branch from 5b9166c to 925e2cb Compare June 22, 2021 10:05
@paroxp paroxp force-pushed the move-from-momentjs-to-datefs branch from 925e2cb to c06836d Compare June 22, 2021 10:33
@paroxp
Copy link
Member Author

paroxp commented Jun 22, 2021

end date should be today, but it's today - 1

I believe this is now fixed :)

Each point on a graph is aggregated over 300 seconds of data, whereas on prod we convert that to 5 minutes (minor thing i reckon)

Actually that's a good spot. If this was to be 10000000s it would still not normalise... I've implemented a hack to take care of it.

not sure if I can trust the graph start point (issue with stub data?)

I would hope so 馃槵

we now say 1 week, previously we said 7 days. i'm fine with that

I think I'm cool with that too 馃

@kr8n3r
Copy link
Contributor

kr8n3r commented Jun 22, 2021

I'd like to test generated graphs and CSV download where data is more reliable. Can we deploy to somewhere?

graphs look look on dev01, metrics range times are UTC (BST -1), csv timestamp looks ok

Copy link
Contributor

@kr8n3r kr8n3r left a comment

Choose a reason for hiding this comment

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

massive piece of work 馃挴

@kr8n3r kr8n3r mentioned this pull request Jun 22, 2021
@paroxp paroxp closed this Jun 22, 2021
@paroxp paroxp deleted the move-from-momentjs-to-datefs branch June 22, 2021 12:28
@paroxp paroxp merged commit c290f70 into main Jun 22, 2021
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.

None yet

2 participants