fix(heatmap): support time and value axes in cartesian coordinate #21492 #21502
+205
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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