-
Notifications
You must be signed in to change notification settings - Fork 19.8k
fix(label): fix label rich style does not inherit the plain label style #20977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…le & add new option `richInheritPlainLabel` to control this behavior.
Thanks for your contribution! The pull request is marked to be Document changes are required in this PR. Please also make a PR to apache/echarts-doc for document changes and update the issue id in the PR description. When the doc PR is merged, the maintainers will remove the |
The changes brought by this PR can be previewed at: https://echarts.apache.org/examples/editor?version=PR-20977@2204b1a |
for (const name in richItemNames) { | ||
if (richItemNames.hasOwnProperty(name)) { | ||
// Cascade is supported in rich. | ||
const richTextStyle = textStyleModel.getModel(['rich', name]); | ||
const richTextStyle = textStyleModel.getModel(['rich', name], richInheritPlainLabel && textStyleModel); | ||
// In rich, never `disableBox`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some thoughts:
Do we need to simplify it to only support richInheritPlainLabel
on the global model?
(I'm not sure)
- pros:
- I guess the most common usage of
richInheritPlainLabel
is when users upgrade to echarts v6, and find that some text style is broken. They can simply setrichInheritPlainLabel: false
on the global option to revert it, without being bothered by debugging. But if they have decided to not to userichInheritPlainLabel: false
and fix the broken style one by one, they can also just modify the text styles directly, but not necessarily setrichInheritPlainLabel: false
on some specific style option (such as,axisLable
,series[i].label
, ...).- If define
richInheritPlainLabel
on the global model, that can be declared intypes.ts
#ECUnitOption
. On the contrary, if supportingrichInheritPlainLabel
every text style, it seems not easy to make a uniform TS declaration. ThetextStyleModel
in this function has been declared asModel<any>
, that makestextStyleModel.get('richInheritPlainLabel')
return anany
type, and pass TS check by chance, but not quite correct.
- If define
- I guess the most common usage of
- cons:
ecModel
is not necessarily exist in this function, tho in most cases it exists. Is it appropriate to just ignore the cases thatecModel
does not exist? I meanif (ecModel) { ecModel.get('richInheritPlainLabel') } else { /* just treat it as richInheritPlainLabel: true */ }
.- Is it possible that it is hard to fix the style and have to rely on
richInheritPlainLabel: false
?
But since no ideal approach, it's also fine to use the current implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the sake of migration, I think supporting the global richInheritPlainLabel
option makes sense, and the type is easy to define. But I hope to also support the richInheritPlainLabel
option in label
style, but keep it undocumented until it is required by developers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that after this changing, test/pie-label-alignTo-adjust.html
throws JS Error in zrender.

The root cause of that Error is related to zr incorrect impl (I'm fixing it.), but not caused by this PR.
However, this PR changes the inheritance behavior, causing the rich style to inherit width
from the outermost label style, which trigger the bug code in zr.
Through this case, I realized that:
- those props,
width
,height
,padding
,margin
,tag
,backgroundColor
,borderColor
,borderWidth
,borderRadius
,shadowColor
,shadowBlur
,shadowOffsetX
,shadowOffsetY
(inTextStylePropsPart
), are inappropriate to inherit. - If the default label style (
static defaultOption = ...
) has props (such as,align
verticalAlign
, and inGauseSeries
), we change the inheritance behavior, that may cause a breaking change. Also need to consider that some default style is set in emphasis state. And users have to reset them in each rich style to correct the style - that might cause the config more complicated than no inheritance.
Thus should we only conservatively only allow inheritance in TEXT_PROPS_WITH_GLOBAL
, i.e., 'fontStyle', 'fontWeight', 'fontSize', 'fontFamily', 'textShadowColor', 'textShadowBlur', 'textShadowOffsetX', 'textShadowOffsetY'
- they are meant to be inheritable (has been inheritable from global option).
Moreover, I found that it's not a correct way to implements the inheritance by
const richTextStyle = textStyleModel.getModel(
['rich', name],
richInheritPlainLabel !== false ? textStyleModel : void 0
);
See test/pie-dataView.html
, that breaks the rich text in pie, because in that case the textStyleModel
is the model of each item and the rich
should be fetched from the original textStyleModel.parent
.
Regarding impl, because in another branch I encountered this issue, I just try to fix that in this way:
Congratulations! Your PR has been merged. Thanks for your contribution! 👍 |
Brief Information
This pull request is in the type of:
What does this PR do?
richInheritPlainLabel
to control this behavior.Fixed issues
Comparison
richInheritPlainLabel
:undefined
richInheritPlainLabel
:true
richInheritPlainLabel
:false
Document Info
One of the following should be checked.
Misc
ZRender Changes
Related test cases or examples to use the new APIs
See test/rich-inherit-plain-label.html
Others
Merging options
Other information