Add user profile heatmap visualization for contributions

[kcne]

Description

This PR addresses #5373 by adding a heatmap visualization on user profile pages to display daily contribution activity over the past year.

Key changes include:

• Added a heatmap container in the user profile view (users/show.html.erb).
• Implemented JavaScript logic (heatmap.js) using CalHeatmap to render the heatmap dynamically based on contribution data.
• Updated localization (config/locales/en.yml) to include tooltips and month/weekday labels for the heatmap.
• Added tests in users_controller_test.rb to validate heatmap data handling.

Screenshots:

How has this been tested?

• Verified heatmap rendering with mock data for different users and activity levels.
• Tested responsiveness and theme support (light/dark mode).
• Checked correct localization of tooltips, month names, and weekday labels.
• Ran automated tests to ensure proper heatmap data handling in the controller.

Let me know if you need further tweaks or enhancements!

[HolgerJeromin]

Oh, I forgot about this.
But the user can now set his "Preferred Website Color Scheme" which should be the basis of the theme not the browser setting.

[Dimitar5555]

It is a very minor nitpick, but is it possible to dynamically determine what's the first weekday based on the user's locale and adjust the heatmap accordingly? Intl.Locale.prototype.getWeekInfo() could be used. It isn't currently available in Firefox but all other browsers have it.

P.S. Added bug 1937867 to Firefox's bug tracker.

[gravitystorm]

What's the source(s) of all the javascript in vendor/? I would expect to see Vendorfile updated, or preferably if these are sourced from e.g. node modules, then they should be included in package.json and added using the assets pipeline. If any of these are source files, i.e. written just for this project, then they should be in app/.

Also, how does the inclusion of popper interact with the popper already included? We end up with //= require popper twice in application.js.

[gravitystorm]

What's the source(s) of all the javascript in vendor/?

OK, I found the answer for the cal-heatmap part of the code, which is available as an npm module. In which case, using package.json will allow us to upgrade to new versions automatically, and would be the preferred option.

[tordans]

UX thoughts:

• Do we want users to be able to disable this feature in their profile? – I am not a fan of this kind of configurations, but we do give a lot more visibility to once activity with this that we had before and the page is public (AKA no login required).
• How do we want to handle the "never contributed" case? Showing the heatmap in this case would suggest "this user might have contributed changes before that time…". – I think it would be best to not show it or show a placeholder instead.

Code comments:

• Do we want to add those JS files to the application js or create a separate contribution_heatmap js for this? https://github.com/openstreetmap/openstreetmap-website/pull/5402/files#diff-0e145ba000e96b1a45d230275e350e4e8514efb4db7dbcfa228fe1003896c9b4R18-R22

[tomhughes]

I've tested the performance of the underlying query and using the user with the most changesets in the last year (just over 50 thousand) it took a fraction over one second which is probably acceptable.

That result (which was a full 365 days of data) serialised to just under 10Kb which is a fair chunk to be caching but hopefully most entries will be smaller than that.

[kcne]

Oh, I forgot about this. But the user can now set his "Preferred Website Color Scheme" which should be the basis of the theme not the browser setting.

Thank you for the suggestion. I’ll refactor accordingly to ensure alignment with the preferred color scheme setting.

It is a very minor nitpick, but is it possible to dynamically determine what's the first weekday based on the user's locale and adjust the heatmap accordingly? Intl.Locale.prototype.getWeekInfo() could be used. It isn't currently available in Firefox but all other browsers have it.

P.S. Added bug 1937867 to Firefox's bug tracker.

I tried dynamically adjusting the start and end weekdays using ghDay as the subdomain, but it rounds to the first and last weeks of the month, making implementation tricky. Accommodating this would require significant effort, which may not be worth it for such a minor adjustment.

What's the source(s) of all the javascript in vendor/? I would expect to see Vendorfile updated, or preferably if these are sourced from e.g. node modules, then they should be included in package.json and added using the assets pipeline. If any of these are source files, i.e. written just for this project, then they should be in app/.

To be honest I wasn’t too familiar with how our assets pipeline works,so I just added the cal-heatmap library and its dependencies in vendor/ and added required code in manifest.js and application.js to make it load correctly. If using package.json is preferred, I can update the PR accordingly. I'm not sure if there is some additional config needed for this to be accomplished or would updating the package.json file would be enough.

Thank you for pointing out the existing popper inclusion. I’ll remove the duplicate entry from application.js and the vendor folder.

[kcne]

I've updated the code to account for the "Preferred Website Color Scheme." Theme settings should now be working correctly.

UX Thoughts:

• Disabling Feature in Profile: Data is already public and open, so I believe all mappers should have a contribution graph. This feature provides valuable insights for more experienced mappers as a reference point to understand others' activity.
• "Never Contributed" Case: Showing an empty heatmap with a fallback message seems like a good approach. From a UX perspective, maintaining a consistent layout across profiles would be more intuitive and visually cohesive.

Code Comments:

• Localizing Starting Week: I attempted to localize the starting week as suggested but couldn't find a clean solution due to limitations with the ghDays subdomain. If anyone has suggestions, I'm open to exploring further.
• Separate JS Files: There's already a heatmap.js file containing heatmap-related functionality, included in application.js for precompilation. I'm hesitant to introduce additional files unless there's a clear benefit. Consolidating heatmap logic here seems to make sense for now.
• Updating package.json: I’ll update the package.json as part of the changes, but I’m unsure if additional configuration is needed. Please let me know if there are any dependencies or settings to consider. @gravitystorm

Also a big thank you to @tomhughes for testing the performance here.
Let me know if further adjustments or discussions are needed!

[AntonKhorev]

Separate JS Files: There's already a heatmap.js file containing heatmap-related functionality, included in application.js for precompilation.

How is it included in application.js if you're including heatmap.js here? But d3 and cal-heatmap are added to application.js, bringing its size up to ~400kb from ~250kb.

[AntonKhorev]

CSP violations, days of week won't be visible if not resolved:

Content-Security-Policy: (Report-Only policy) The page’s settings would block an inline style (style-src-attr) from being applied

[AntonKhorev]

I've updated the code to account for the "Preferred Website Color Scheme." Theme settings should now be working correctly.

It's not going to work correctly because our Auto option follows prefers-color-scheme which can change any time. If it does, you'll get for example this:

Looks like cal-heatmap doesn't have a proper auto scheme "as not all websites support dark/light mode".

You'd have to then setup a listener like this but without using Leaflet of course and redraw the heatmap.

Same is true for #5426 by the way.

[hlfan]

You'd have to then setup a listener like this but without using Leaflet of course and redraw the heatmap.

Same is true for #5426 by the way.

Any other change to the theme of the page without reloading will break most of the CSS theming anyway since the stylesheets were split in #5362 by the way.

It would be great to have a global leaflet-independent watcher where clients can add themselves to a callback list.

[AntonKhorev]

Any other change to the theme of the page without reloading will break most of the CSS theming anyway since the stylesheets were split in #5362 by the way.

You don't need to change the theme of the page, neither here, nor in #5426.

Or do you say that you haven't tried switching prefers-color-scheme while in Auto scheme? Then try it with browser dev tools for example.

It would be great to have a global leaflet-independent watcher where clients can add themselves to a callback list.

Leaflet code is just a wrapper for addEventListener. You can do the same with jQuery.

[hlfan]

You don't need to change the theme of the page

I did that for testing, but since listening increased the complexity unnecessarily, I left that for a second pass.

But suppose the site needs a theme watcher anyway because the cal-heatmap doesn't want to let CSS do the color mixing theme-agnostically. In that case, instead of having two listeners, a common solution that includes MutationObservers outside of jQuery would be the one with the least overhead.

[AntonKhorev]

Why MutationObservers?

[AntonKhorev]

Also the conditions under which watching prefers-color-scheme are different for this PR and #5426. Here you need to watch if the website theme is auto, in #5426 you need to watch when the website and the map themes are both auto. So maybe you don't want one global watcher.

[hlfan]

The MutationObserver thought came from my tinkering with the site locally wanting to reduce the reloads, forgetting that a toggle if added would already have onchange events.

So maybe you don't want one global watcher.

Yeah, I kinda missed that... Still, having a similar style on such similar functions and having them moved to some unified location would be a nice thing to have, currently, they could be much more different. But that's more of a refactor thing if both are merged.

[kcne]

Separate JS Files: There's already a heatmap.js file containing heatmap-related functionality, included in application.js for precompilation.

How is it included in application.js if you're including heatmap.js here? But d3 and cal-heatmap are added to application.js, bringing its size up to ~400kb from ~250kb.

I've moved the import to heatmap.js. Should be resolved now.

I've updated the code to account for the "Preferred Website Color Scheme." Theme settings should now be working correctly.

It's not going to work correctly because our Auto option follows prefers-color-scheme which can change any time. If it does, you'll get for example this:

Looks like cal-heatmap doesn't have a proper auto scheme "as not all websites support dark/light mode".

You'd have to then setup a listener like this but without using Leaflet of course and redraw the heatmap.

Same is true for #5426 by the way.

Added the logic to handle the auto prefered-color-changes. Should be resolved now as well.

CSP violations, days of week won't be visible if not resolved:

Content-Security-Policy: (Report-Only policy) The page’s settings would block an inline style (style-src-attr) from being applied

I'm working on resolving this CSP violations. Right now I'm trying to generate nonce for the .js file and use that to validate and transpass the CSP violation. I'm not sure if it is the right approach for this since I never had experience dealing with similar stuff before. If there is a more elegant and compact solution, please feel free to point it out.

Thank you.

[hlfan]

Added the logic to handle the auto prefered-color-changes. Should be resolved now as well.

For the wrong one though. Another copy of the html's bs-theme attribute isn't necessarily helpful, and the media query is still not being listened to.

[hlfan]

I'm sorry, but I don't see where a re-draw would be triggered.

[hlfan]

I'd recommend window.matchMedia("...").onchange = xy due to the depreciation of matchMedia.addEventListener.

[kcne]

The test failing here doesn't have nothing to do with the changes introduced in this PR. I tried force pushing again to rerun checks but again got failing test on different version of Ruby this time, which is weird. Is there some kind of bug in CI/CD right now or should I push again to rerun checks?

After another checks re-run, all tests are passing as expected.

[AntonKhorev]

Now there's a ton of registry.yarnpkg.com -> registry.npmjs.org changes.

[kcne]

Must have messed this up during conflict. I will try to restore the file and do rebase again. Thank you.

[AntonKhorev]

Now there are no updates to yarn.lock.