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

[Date] Relative date badge #2244

Merged
merged 6 commits into from
Jan 4, 2019
Merged

Conversation

Ang-YC
Copy link
Contributor

@Ang-YC Ang-YC commented Oct 31, 2018

This pull request is related to issue #749

Endpoint /date/{timestamp}.svg
Regex /^\/date\/([0-9]+)\.(svg|png|gif|jpg|json)$/
Example /date/1545696000000.svg?label=christmas&colorB=red
Result revision

@shields-ci
Copy link

shields-ci commented Oct 31, 2018

Messages
📖 ✨ Thanks for your contribution to Shields, @Ang-YC!

Generated by 🚫 dangerJS against 45e85a7

@paulmelnikow paulmelnikow added the service-badge New or updated service badge label Oct 31, 2018
Copy link
Member

@chris48s chris48s left a comment

Choose a reason for hiding this comment

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

Thanks for working on this. This is in very good shape already. I've left a few comments inline.

The one other thing that occurs to me is: what about timezones? This becomes relevant if the target timestamp is very soon or very recent, e.g: It seems like it would be helpful to allow the user to optionally pass a timezone as a second param and default to UTC if its empty. I can see that being a common question/issue if we deploy this without it.

Edit: I may be over-complicating this for no reason. If we're taking a timestamp as input (which means the input inherently had to be converted to UTC) and the delta is relative, is this just completely irrelevant? It is possible I do not know how to timezone...

Edit2: Definitely ignore the timezone thing. To provide a timestamp as input, the user should have already converted their event from their local timezone to UTC. Apologies for confusing the issue

@@ -109,6 +109,12 @@ function formatDate(d) {
return dateString.replace(` ${moment().year()}`, '').toLowerCase()
}

function formatRelativeDate(d) {
Copy link
Member

Choose a reason for hiding this comment

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

I think this would be clearer if we called the param timestamp. d is not very descriptive

static render({ relativeDateString }) {
return {
message: relativeDateString,
color: relativeDateString === 'invalid date' ? 'red' : 'blue',
Copy link
Member

Choose a reason for hiding this comment

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

Could we use 'grey' for the error rather than red

title: 'Relative date',
urlPattern: ':timestamp',
staticExample: this.render({ relativeDateString: '2 days ago' }),
exampleUrl: '1540814400000',
Copy link
Member

Choose a reason for hiding this comment

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

I found it confusing that we're using a 13 digit (no of milliseconds) timestamp here instead of the more usual 10 digit unix format (no of seconds). We probably don't need millisecond precision for this application, so it might be worth going with the 10 digit format. What do you think?
Either way, we should probably pass a 'documentation' key here which explains which format we use and maybe link to a useful converter.

Copy link
Member

Choose a reason for hiding this comment

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

Sorry.. just realised that comment about a documentation key might not have been clear. There's an example of this here - we define a docs var here:

const docs = `
<p>
Using a web browser, you can find the ID in the url here:
</p>
<img
src="https://user-images.githubusercontent.com/6497721/46358801-1bcb3200-c668-11e8-9963-931397853945.PNG"
alt="The ID is the number found right after ?id= in the URI" />
<p>
In the steam client you can simply just Right-Click and 'Copy Page URL' and follow the above step
</p>
<img
src="https://user-images.githubusercontent.com/7288322/46567027-27c83400-c987-11e8-9850-ab67d987202f.png"
alt="Right-Click and 'Copy Page URL'">

and then pass it in a key called 'documentation' when we define the examples:

{
title: 'Steam Collection Files',
exampleUrl: '180077636',
urlPattern: ':id',
staticExample: this.render({ size: 32 }),
keywords: ['steam'],
documentation: docs,
},

that renders it in the modal popup from the index page :)

Copy link
Member

Choose a reason for hiding this comment

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

I feel like ms may make more sense as we are parsing it straight to moment.js rather than using time * 1000 or time + '000',
Although the end user wouldn't necessarily know we are using javascript.

Copy link
Member

Choose a reason for hiding this comment

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

Let's go with seconds. JavaScript aside, time as seconds since 1/1/70 UTC seems more popular than any other way of measuring time.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah. We should definitely support the 10-digit format. If you wanted, we could do both. If we declare this route:

static get route() {
  return {
    base: 'date',
    format: '([0-9]{13}|[0-9]{10})',
    capture: ['timestamp'],
  }
}

we'll capture either a 10 or 13-digit timestamp. Then we can process the timestamp appropriately based on length and we'll reject invalid formats. Everyone's happy.

@paulmelnikow
Copy link
Member

@Ang-YC It would be great to get this feature shipped! Would you be up for addressing these comments? If not, no problem, I or one of the other maintainers can pick it up.

@Ang-YC
Copy link
Contributor Author

Ang-YC commented Dec 17, 2018

Hey @paulmelnikow, thanks for reminding me about this. Sure I will update it to follow their comments. However, should I use 10 or 13 digits timestamp as mentioned by @chris48s? Thanks!

@paulmelnikow
Copy link
Member

Hi @Ang-YC did you see the response above? Let's support both, so a user can provide either 10 or 13. Would be great to get this merged!

@Ang-YC
Copy link
Contributor Author

Ang-YC commented Jan 3, 2019

Hi @paulmelnikow, thanks for confirming. However, timestamp is not always 10 or 13 digits, For example, 0 is 1 digit only and represents 1/1/1970.

When the input is 1000000000, it is 12/1/1970 when treated as milliseconds and 9/9/2001 when treated as seconds.

@paulmelnikow
Copy link
Member

Okay, let's just go with the seconds version then.

@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-2244 January 4, 2019 15:47 Inactive
@paulmelnikow paulmelnikow temporarily deployed to shields-staging-pr-2244 January 4, 2019 16:27 Inactive
@paulmelnikow
Copy link
Member

@paulmelnikow paulmelnikow merged commit f6357da into badges:master Jan 4, 2019
@shields-deployment
Copy link

This pull request was merged to master branch. This change is now waiting for deployment, which will usually happen within a few days. Stay tuned by joining our #ops channel on Discord!

After deployment, changes are copied to gh-pages branch:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service-badge New or updated service badge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants