Add a "Calendar view"

[justin-jiajia]

Implement #338 .

[muety]

Thanks a lot for this, great contribution!

Regarding the overall implementation, I'd probably suggest a slightly different approach. You current implementation comes with a few drawbacks:

• "Duplicate" logic to aggregate durations
• Inefficient, because operating on raw heartbeats for each request instead of leveraging pre-aggregated summaries
• Not respected custom mapping or project aliases

To overcome these (and thus also improve performance), I'd probably utilize the already existing summary computation logic. I'd (very roughly speaking) do approximately this:

• Use SplitRangeByDays (search code for examples), to break down the requested interval into single days
• Use SummaryService.Aliased() (just like in many other places throughout Wakapi) to fetch fetch summaries for each day
• Construct the DailyProjectStat view model from an array of summaries, i.e. introduce methods func NewDailyProjectStats(summaries []*models.Summaries) []*DailyProjectStat { ... } or something, e.g. similar to here.

[muety]

Thanks for implementing my change requests!

Do you think we should limit the calendar view component to a maximum number of days? Because when choosing a very large – if not All Time – interval, the chart becomes unreadable and super inefficient (blocked my browser tab for almost 30 seconds). Would love to hear your thoughts on that.

[muety]

Can you explain what's the point of Add(-1*time.Second)?

[justin-jiajia]

I searched the repo for the example of SplitRangeByDays. I got the following code snippet:

wakapi/routes/compat/wakatime/v1/summaries.go

Lines 135 to 150 in a02c96e

	intervals := utils.SplitRangeByDays(overallParams.From, overallParams.To)
	summaries := make([]*models.Summary, len(intervals))
	// filtering
	filters := helpers.ParseSummaryFilters(r)
	for i, interval := range intervals {
	summary, err := h.summarySrvc.Aliased(interval[0], interval[1], user, h.summarySrvc.Retrieve, filters, end.After(time.Now()))
	if err != nil {
	return nil, err, http.StatusInternalServerError
	}
	// wakatime returns requested instead of actual summary range
	summary.FromTime = models.CustomTime(interval[0])
	summary.ToTime = models.CustomTime(interval[1].Add(-1 * time.Second))
	summaries[i] = summary
	}

As it includes both SplitRangeByDays and summarySrvc.Aliased, I wrote my code according to it.

I didn't know whether the Aliased takes account of the heartbeats exactly sent at the last second or not, so I thought this line was better as the last second (or the first second on the next day) won't be calculated twice.

[muety]

Thanks for explaining. You should be good to go with using the exact end date, summary calculation logic will take care of the rest 👍.

[justin-jiajia]

Could you please tell me a bit more? What is exact? Should I remove the add(-1s) or not?

[muety]

Sorry for being very picky about code architecture here, but: following the notion of a "layered architecture" / adhering to the "dependency rule", the service layer shouldn't have any referenced to view models. They rather belong to what you could call "presentation layer" or so and thus only be used at the level of routes.

I'd prefer to go for this implementation:

• Move the DailyProjectViewModel definition to models/view
• In that same file, add a method NewDailyProjectStats([]*models.Summary summaries)
• Move this function here to inside SummaryHandler and change it in a way that it (1) retrieves the required list of summaries from the service and (2) calls the just mentioned NewDailyProjectStats to have it construct the actual view model from it

So in summary:

• Service remains mostly unchanged
• Route is responsible for fetching summaries and calling to construct view model
• View model construction (from a list of summaries) is implemented next to the view model itself

Again, sorry for dragging this out so much! :-|