-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Conversation
There was a problem hiding this 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
lib/text-formatters.js
Outdated
@@ -109,6 +109,12 @@ function formatDate(d) { | |||
return dateString.replace(` ${moment().year()}`, '').toLowerCase() | |||
} | |||
|
|||
function formatRelativeDate(d) { |
There was a problem hiding this comment.
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
services/date/date.service.js
Outdated
static render({ relativeDateString }) { | ||
return { | ||
message: relativeDateString, | ||
color: relativeDateString === 'invalid date' ? 'red' : 'blue', |
There was a problem hiding this comment.
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
services/date/date.service.js
Outdated
title: 'Relative date', | ||
urlPattern: ':timestamp', | ||
staticExample: this.render({ relativeDateString: '2 days ago' }), | ||
exampleUrl: '1540814400000', |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
shields/services/steam/steam-workshop.service.js
Lines 10 to 22 in 52d642c
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:
shields/services/steam/steam-workshop.service.js
Lines 181 to 188 in 52d642c
{ | |
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 :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@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. |
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! |
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! |
Hi @paulmelnikow, thanks for confirming. However, timestamp is not always 10 or 13 digits, For example, When the input is |
Okay, let's just go with the seconds version then. |
This pull request is related to issue #749
/date/{timestamp}.svg
/^\/date\/([0-9]+)\.(svg|png|gif|jpg|json)$/
/date/1545696000000.svg?label=christmas&colorB=red