fix: Markline causes type error when used with series.encode #21336
+459
−6
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.
Brief Information
This pull request is in the type of:
What does this PR do?
Fixes a type error that causes
ordinalMetato be undefined when used on encoded axes withseries.encode.Fixed issues
Details
Before: What was the problem?
When defining a markline within a series that uses the
series.encodeoption, a type error would be thrown thatordinalMetais undefined. It seems like due to this axis encoding, the series can not figure out the correct dimension to use for a markline. I feel its the same for markarea too.After: How does it behave after the fixing?
In the initial case reported in issue #21300 I used the broken example as input and created a test html file to render the chart, and I noticed the marklines appearing again without needing to use a workaround of an empty/invisible scatter series.
Document Info
One of the following should be checked.
Misc
Security Checking
ZRender Changes
Related test cases or examples to use the new APIs
test/markLine-dataset-encode-fix.html
test/ut/spec/component/marker.test.ts
Merging options
Other information
If anything needs to be changed or updated, please let me know. This is a bug affecting my workplace too so I felt I'd follow the ffmpeg motto of "Talk is cheap, send patches".
Thanks.