fix(heatmap): support time and value axes in cartesian coordinate #21492#21502
fix(heatmap): support time and value axes in cartesian coordinate #21492#21502SakshamSinghal20 wants to merge 1 commit intoapache:masterfrom
Conversation
|
Thanks for your contribution! Please DO NOT commit the files in dist, i18n, and ssr/client/dist folders in a non-release pull request. These folders are for release use only. |
|
@plainheart @100pah could you please review this at your convenience? |
|
Any updates on this? It would be really helpful if the heatmap supported a time axis. Ideally, the axis labels could use time formatters similar to the regular time axis, for example: and the axis would automatically prioritize displaying day, month, and year labels when overlaps occur. Currently, using a category axis, I have to approximate this with |
This pull request is in the type of:
bug fixing
new feature
others
What does this PR do?
Fixes heatmap axis type validation inconsistency between dev and prod builds, enabling support for time and value axes.
Fixed issues
#21492 : Heatmap with time/value axes throws error in dev but works in prod
Details
Before: What was the problem?
Heatmaps using xAxis.type = "time" or "value" and yAxis.type = "value" behaved differently across builds:
Dev build: Threw runtime error "Heatmap on cartesian must have two category axes"
Prod build: Rendered successfully without errors
The root cause was validation code wrapped in DEV blocks (lines 186-193 in HeatmapView.ts) that enforced category axes only in development builds. This validation was stripped during production minification, creating inconsistent behavior and making it unclear what axis types are officially supported.
After: How does it behave after the fixing?
Both dev and prod builds now consistently support heatmaps with any combination of category, time, or value axes:
Removed the restrictive DEV validation checks
Implemented dynamic cell size calculation:
Category axes with onBand: Use getBandWidth() (preserves original behavior)
Time/Value axes: Calculate cell dimensions as pixelSpan / dataSpan
Both X and Y axes are handled independently based on their type
The fix is fully backward compatible—existing heatmaps with category axes continue to work exactly as before, while time and value axes are now officially supported in both build types.
Document Info
One of the following should be checked.
This PR doesn't relate to document changes
The document should be updated later
The document changes have been made in apache/echarts-doc#xxx
Misc
Security Checking
This PR uses security-sensitive Web APIs.
ZRender Changes
This PR depends on ZRender changes (ecomfe/zrender#xxx).
Related test cases or examples to use the new APIs
Test case added: test/heatmap-time-value-axes.html demonstrates heatmap with time xAxis and value yAxis.
Merging options
Please squash the commits into a single one when merging.
Other information
N/A