-
Notifications
You must be signed in to change notification settings - Fork 286
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
Convert Last Commit Date to "Time Ago" Format #12
Comments
I can work on this if you'd like. |
That would be awesome! |
Are you sure you want the dates converted at build time? This would mean that the last commit time shown would then be based on the difference between the repo's last commit time and the time the site was last built. Unless the site rebuilds every hour the last committed "time ago" will be stale. |
You're right, that wouldn't work. I suppose the only solution is client side JS? I had an implementation using JS but it slowed the site down and you could see the text change from "Oct 9,2019" to "3 Hours ago" after the site had loaded. Maybe you could implement something more performant? |
Let me think on/experiment with it and see if I can come up with something that has acceptable performance. |
I thought about this further and come to the realization that any form of last commit date shown will be stale, even if calculated on the front-end, because as it is now, the repo's last commit date is also being retrieved at build time. To recap, if the conversion is done at build time the last commit value is stale because it is based on the difference between build time and the repo's last commit time; while if conversion is done in the front-end the last commit time will become stale over time because the repo's last commit time was captured at build time and there may have been more recent commits since the site was built—either way the last commit values are only accurate when the build is fresh and grow stale as time marches forward. <tangent> Using the repo hauke96/hugo-theme-hamburg as an example:
Given the above, the value used as the last commit ("2019-08-23T13:18:15Z") is really representative of the dev branch, not the master branch. If the last commit is supposed to representative of repo activity that might be fine, it depends on what is meant to be conveyed and may be worthy of clarification on the front-end (e.g. maybe "last activity" is better instead of "last commit" which I think might be thought of as "last commit on master"). Back to the issue at hand... The naive approach would be to retrieve and update the last commit time on the front-end. This would be way too slow and there would be rate limit issues with the GitHub API (not to mention it's bad practice to bang away at an external API per page request when the results could be cached). The only reasonable way I can think of to keep this data fresh (but still not real-time) is to have a server-side process which retrieves and stores the needed data at intervals (daily/hourly/etc.). This could probably be as simple as a JavaScript file generated at intervals that resides server side that contains a single JSON object with pairs of repo name (key) and time ago (value), where the time ago is calculated as of the refresh time (this file generation would be similar to what the site's existing generate-github.js script is doing currently pre-build). Then that single JSON file could be brought in to the page via a script tag and some JS added to perform the update of the last commit divs. I think that would make it the fastest it could be. I should also note, that depending on how many themes this site grows to have the single JSON file approach may not scale. I'm not sure if you want or need the added complexity of the above solution though, so I'll await your thoughts on this. |
Thank you for such a well researched answer. I am OK with the staleness of the last_commit date we retrieve from Github. It's adequate for people to know that the Repo has been updated in the last few days, or months or years. Anything that has been updated in the last month is still indicative of a freshly maintained repo, anything that is a few months or even years old is something to be concerned about. It would be best if we could get the last_commit from only the master branch. You are correct, this is intended to represent "last commit on master".
Probably in
And then see which library is most performant out of moment.js, datefns and timeago.js |
Another thing to consider is we do actually allow theme submissions on other branches than master. So if the submitted branch is develop I wonder if the last_commit should be taken from that branch. |
Would you like me to open a separate issue to address where the last commit is sourced from, or just keep it part of this issue? Whether it's separate or kept here I can work on that too. Based on the notes you left above, I'll continue to work on this and probably have a PR ready for review sometime early next week. |
I think a seperate issue makes sense. |
Just wanted to drop an update to say I haven't had time this week to work on this, but have time set aside on Sunday and expect to drop a PR for review sometime Sunday night. |
@JugglerX I've been playing with this and have a version that is using jQuery and the timeago library working. I've been thinking though to minimize the amount of updates made on the page we could specify a cut-off amount of time past since the last commit to consider "probably inactive" and at build time see if the last commit is beyond that cut-off time and just use something like "no recent activity". For example, any repo with a last commit date over 3 months ago, would get "no recent activity" applied at build time. The rest would get the time ago formatting applied. What do you think of that strategy and if you like it what would you want to use for the cut-off period? |
You can give what I had so far a review. A few notes:
If you rather it just replace the date or have any other feedback that requires me to resubmit the PR just let me know. |
@rgroves I think your solution is good given the constraints. I like how you have added the time ago as a seperate line ( your right it feels less jarring ) - I'll probably tweak the design of this a bit. I'll go ahead and close this issue and merge the PR. I also think your suggestion to apply a cutoff to older themes has merit and could be used more broadly to limit the number of actual themes loaded on the page. I had actually started working on a script for this in Basically this script should iterate through the We can then use this property in the hugo templates to a) modify the date so it is not effected by the timeago.js b) set a class on the theme and shade back the opacity or put a grey border on it or something and add a badge that says "stale" c) not render the themes at all. I'm considering create a new page called "all themes" where stale themes (as above) and other themes with low quality indicators will still be shown. The homepage will remain and will be "latest themes" or "popular themes" and have a smaller selection of higher quality themes (based on metrics not curation) |
Each theme displays the date of its last commit using a standard date format of "last commit Oct 19, 2019". It would be better if it used a "time ago" format ie "last commit 2 hours ago"
The exact formatting and details of the time ago format can be whatever makes sense.
We'd prefer not use javascript which modifies the DOM in the client, as it will significantly impact performance. It would be great the date format was converted at build using standard Hugo functionality.
The text was updated successfully, but these errors were encountered: