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

Heatmap days clickable #13935

Merged
merged 13 commits into from
Feb 20, 2021
Merged

Heatmap days clickable #13935

merged 13 commits into from
Feb 20, 2021

Conversation

LFriede
Copy link
Contributor

@LFriede LFriede commented Dec 10, 2020

Hi,

I filed an issue (#10843) about making the days in the heatmap clickable like here on github to display the actions on a specific day. I've implemented it with this PR.

@techknowlogick techknowlogick added the topic/ui Change the appearance of the Gitea UI label Dec 10, 2020
@techknowlogick
Copy link
Member

Could you provide a screenshot/gif of this PR in action?

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 10, 2020
@codecov-io
Copy link

codecov-io commented Dec 10, 2020

Codecov Report

Merging #13935 (9f31f44) into master (487f2ee) will decrease coverage by 0.00%.
The diff coverage is 42.15%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #13935      +/-   ##
==========================================
- Coverage   42.21%   42.20%   -0.01%     
==========================================
  Files         767      771       +4     
  Lines       81624    82078     +454     
==========================================
+ Hits        34458    34644     +186     
- Misses      41531    41784     +253     
- Partials     5635     5650      +15     
Impacted Files Coverage Δ
models/action.go 48.52% <0.00%> (-2.42%) ⬇️
models/migrations/migrations.go 2.59% <ø> (ø)
models/migrations/v166.go 0.00% <0.00%> (ø)
models/migrations/v172.go 0.00% <0.00%> (ø)
models/migrations/v173.go 0.00% <0.00%> (ø)
models/session.go 0.00% <0.00%> (ø)
models/user.go 53.05% <ø> (+0.38%) ⬆️
modules/context/context.go 58.05% <0.00%> (-0.45%) ⬇️
modules/indexer/code/elastic_search.go 1.72% <0.00%> (-0.02%) ⬇️
modules/migrations/github.go 77.77% <0.00%> (-1.99%) ⬇️
... and 57 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f3e64f6...9f31f44. Read the comment docs.

@6543 6543 added the type/enhancement An improvement of existing functionality label Dec 11, 2020
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Dec 11, 2020
@6543 6543 added this to the 1.14.0 milestone Dec 11, 2020
@silverwind
Copy link
Member

Can you make it clear the filter when clicking the same date again?

models/action.go Outdated
var dateLow time.Time
var dateHigh time.Time

dateLow, _ = time.Parse("2006-1-2", opts.Date)
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't ignore the error.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
dateLow, _ = time.Parse("2006-1-2", opts.Date)
var err error
dateLow, err = time.Parse("2006-1-2", opts.Date)
if err != nil {
return fmt.Errorf("Unable to parse %s: %v", opts.Date, err)
}

should do it.

Copy link
Contributor Author

@LFriede LFriede Dec 11, 2020

Choose a reason for hiding this comment

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

I think we have two ways to handle the error. The way @zeripath suggested or by just logging the error. Returning the error will cause a 500 error code. Logging the error seems to be closer to the behavior on other parts of gitea. For example if I use invalid parameters for sorting the issue list it just don't sort instead of throwing an error.

I'm not sure which way is better. What do you think?

dateLow, err := time.Parse("2006-1-2", opts.Date)
if err != nil {
	log.Warn("Unable to parse %s, filter not applied: %v", opts.Date, err)
} else {
	dateHigh := dateLow.Add(86399000000000) // 23h59m59s

	cond = cond.And(builder.Gte{"created_unix": dateLow.Unix()})
	cond = cond.And(builder.Lte{"created_unix": dateHigh.Unix()})
}

Copy link
Member

@silverwind silverwind Dec 11, 2020

Choose a reason for hiding this comment

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

I like yours because if we fail to parse the date, there is no reason to continue as the functions below would fail as well (would that be a panic?).

@LFriede
Copy link
Contributor Author

LFriede commented Dec 11, 2020

I'll do a gif, filter clearing by clicking again, and error checking as soon as possible :)

@LFriede
Copy link
Contributor Author

LFriede commented Dec 15, 2020

I pushed the changes and here is a gif.

gitea_heatmap

@silverwind
Copy link
Member

Please apply this diff for more robust JS:

diff --git a/web_src/js/components/ActivityHeatmap.vue b/web_src/js/components/ActivityHeatmap.vue
index c06fd8799..b9a3aa3a6 100644
--- a/web_src/js/components/ActivityHeatmap.vue
+++ b/web_src/js/components/ActivityHeatmap.vue
@@ -41,21 +41,22 @@ export default {
       no_contributions: 'No contributions',
     },
   }),
   methods: {
-    handleDayClick(event) {
+    handleDayClick(e) {
       // Reset filter if same date is clicked
-      const day = window.location.search.match(/\?date=(\d{4})-(\d{1,2})-(\d{1,2})/);
-      if (day !== null) {
-        if (day.length === 4) {
-          if ((parseInt(day[1]) === event.date.getFullYear()) && (parseInt(day[2]) === (event.date.getMonth() + 1)) && (parseInt(day[3]) === event.date.getDate())) {
-            window.location.search = '';
-            return;
-          }
-        }
+      const params = new URLSearchParams(document.location.search);
+      const queryDate = params.get('date');
+      const clickedDate = e.date.toISOString().substring(0, 10);

+      if (queryDate && queryDate === clickedDate) {
+        params.delete('date');
+      } else {
+        params.set('date', clickedDate);
       }

-      window.location.search = `?date=${event.date.getFullYear()}-${event.date.getMonth() + 1}-${event.date.getDate()}`;
+      const newSearch = params.toString();
+      window.location.search = newSearch.length ? `?${newSearch}` : '';
     }
   },
 };
 </script>

@LFriede
Copy link
Contributor Author

LFriede commented Dec 19, 2020

Honestly I didn't knew the URLSearchParams object, thats the better solution of course.

Your date comparison trades 2020-2-1 and 2020-02-01 as different dates, thats fine as long as nobody tries to edit the url by hand. The regex approach handles that case (on purpose). So I think we should combine both to something like this:

    handleDayClick(e) {
      // Reset filter if same date is clicked
      const params = new URLSearchParams(document.location.search);
      const queryDate = params.get('date');

      let sameDate = false;
      if (queryDate !== null) {
        const day = queryDate.match(/(\d{4})-(\d{1,2})-(\d{1,2})/);
        if (day !== null) {
          if (day.length === 4) {
            if ((parseInt(day[1]) === e.date.getFullYear()) && (parseInt(day[2]) === (e.date.getMonth() + 1)) && (parseInt(day[3]) === e.date.getDate())) {
              sameDate = true;
            }
          }
        }
      }

      if (sameDate) {
        params.delete('date');
      } else {
        params.set('date', `${e.date.getFullYear()}-${e.date.getMonth() + 1}-${e.date.getDate()}`);
      }

      const newSearch = params.toString();
      window.location.search = newSearch.length ? `?${newSearch}` : '';
    }

Do you agree?

@silverwind
Copy link
Member

No, I'd enforce YYYY-MM-DD, it's a well-accepted standard format for a date, no need to support anything else.

@LFriede
Copy link
Contributor Author

LFriede commented Dec 19, 2020

Okay, I pushed your version but with a small correction. Timezone is substracted from the date because at least in Germany (UTC+2) it returns one day off since toISOString() formats the date to UTC+0.

@@ -159,6 +159,7 @@ func Dashboard(ctx *context.Context) {
IncludePrivate: true,
OnlyPerformedBy: false,
IncludeDeleted: false,
Date: ctx.Query("date"),
Copy link
Member

Choose a reason for hiding this comment

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

You're missing this parameter in routers/user/profile.go.

models/action.go Outdated
IncludePrivate bool // include private actions
OnlyPerformedBy bool // only actions performed by requested user
IncludeDeleted bool // include deleted actions
Date string // the day we want activity for: YYYY-M-D
Copy link
Member

Choose a reason for hiding this comment

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

Would you mind changing the signature of GetFeedsOptions to not specify a single date, but to contain a time range (i.e. after, before time.Time, populate these values in home.go/profile.go)? In #14080 I'm making this struct reusable for the heatmap, and a time-range filter would be welcome for the heatmap too (for #5439).

models/action.go Outdated Show resolved Hide resolved
@6543
Copy link
Member

6543 commented Feb 2, 2021

@LFriede would be nice if you can resolve conflicts :)

@LFriede
Copy link
Contributor Author

LFriede commented Feb 3, 2021

Sorry for the late reply.

  • Added forgotten date parameter on profile.go like @noerw pointed out. I'd prefer to add date range in another PR if thats okay.
  • Edited parsed date format like @silverwind said.
  • resolved conflicts

Copy link
Member

@noerw noerw left a comment

Choose a reason for hiding this comment

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

looks good, please merge current master

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Feb 20, 2021
@techknowlogick techknowlogick merged commit 343c756 into go-gitea:master Feb 20, 2021
@LFriede LFriede mentioned this pull request Feb 21, 2021
7 tasks
@go-gitea go-gitea locked and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. topic/ui Change the appearance of the Gitea UI type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants