Convert Last Commit Date to "Time Ago" Format about jamstackthemes HOT 14 CLOSED

That would be awesome!

from jamstackthemes.

Let me think on/experiment with it and see if I can come up with something that has acceptable performance.

from jamstackthemes.

@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 scrub-themes.js but its pretty broken right now.

Basically this script should iterate through the data/themes.json and compare the last commit date against todays time. If it is older then X then we add a new key stale: true

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)

from jamstackthemes.

I can work on this if you'd like.

from jamstackthemes.

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.

from jamstackthemes.

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?

from jamstackthemes.

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>
Another thing of note that I came across while looking into this is that the value being used to report the last commit is the "pushed_at" key of the github repo object. This time value is representative of the time a commit was made to any branch of the repo, not just the master branch. So this is not reflective of recency of the master branch that users would probably be looking for. I think the correct value to use would be the date of the last commit of the master branch.

Using the repo hauke96/hugo-theme-hamburg as an example:

• Retrieving the repo's object and looking at the pushed_at key we see (at the time of this writing): "2019-08-23T13:18:15Z"
• Retrieving the master branch's last commit object and looking at the commit.author.date key we see (at the time of this writing): "2019-08-19T23:59:44Z"
• Retrieving the dev branch's last commit object and looking at the commit.author.date key we see (at the time of this writing): "2019-08-23T13:18:14Z"

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").
</tangent>

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.

from jamstackthemes.

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".

• We are OK with a slightly stale last_commit generated at build time.
• Get the correct value for last_commit from the Github API in the generate-github.js script. It should be the "last commit on master"
• Still implement a solution that shows the last_commit as time ago format but the time agos current date used in the comparison must be a realtime timestamp. After resisting the inevitable it seems like client-side javascript is the only solution here.

Probably in scripts.js we should have one iteration over all themes where any DOM manipulation is done.

document.querySelectorAll(".theme").forEach((theme) => {
 // find relevant DOM node
// apply date library formating
// do other DOM manipulations in the future.
})

And then see which library is most performant out of moment.js, datefns and timeago.js

from jamstackthemes.

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.

from jamstackthemes.

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.

from jamstackthemes.

I think a seperate issue makes sense.

from jamstackthemes.

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.

from jamstackthemes.

@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?

from jamstackthemes.

You can give what I had so far a review. A few notes:

• I saw that the jQuery and timeago libraries were already in themes/jamstackthemes/assests/js/libs so I just pulled them in via the baseof layout template. Let me know if that should be done a different way.
• I added the time ago format under the last commit date itself within parenthesis that are initially set to "(...)" before being updated. This looked less jarring then actually replacing the date. If you want to see it where it's just replacing the date you can swap this into themes/jamstackthemes/layouts/partials/last-commit.html:

<div class="last-commit">
  last commit <time class="timeago" datetime="{{ dateFormat "2006-01-02T15:04:05Z07:00" .last_commit }}">{{ dateFormat "Jan 2, 2006" .last_commit }}</time>
</div>

If you rather it just replace the date or have any other feedback that requires me to resubmit the PR just let me know.

from jamstackthemes.