Please confirm that you have searched existing issues in the repo
Yes, I have searched the existing issues
Any related issues?
#2463, #1715
What is the area that this feature belongs to?
Testing
Is your feature request related to a problem? Please describe.
There are two issues that arise from #2463 (and I'll be quoting myself):
Inconsistent naming in NodeProcessor.data.ts
The naming conventions of the test inputs in NodeProcessor.data.ts are inconsistent. Many of the elements there have a test to check if the slots do override the attributes of the elements, but they are named in two separate ways:
PROCESS_[ELEMENT]_ATTRIBUTES_NO_OVERRIDE
PROCESS_[ELEMENT]_[ATTRIBUTE]_SLOT_TAKES_PRIORITY
I think that's why the author of #2053 wrote another constant called PROCESS_PANEL_HEADER_SLOT_TAKES_PRIORITY when the constant PROCESS_PANEL_ATTRIBUTES_NO_OVERRIDE tests for the exact same thing. That's why I have an expect statement after each of these two tests, because in both times the logger is called with the same input.
Logger warnings still inconsistent
With the merging of #2053, Panels, Dropdowns, Modals and Popovers print warnings to the console if there are slots overriding the element attributes. However, other elements such as Quizzes and QOptions do not print warnings when this happens. This is because in the code of MdAttributeRenderer.ts, not every attribute is checked to see if there is an overriding slot, so the logger will not warn if the unchecked attributes are overridden.
Describe the solution you'd like
Firstly, standardise the constant names in NodeProcessor.data.ts to PROCESS_[ELEMENT]_[ATTRIBUTE]_SLOT_TAKES_PRIORITY as it is clearer than the other alternative.
To fix the inconsistent logger warnings once and for all, implement this new method
processAttribute(node, attribute, isInline, slotName = attribute) {
if (!this.hasSlotOverridingAttribute(node, attribute, slotName) {
this.processAttributeWithoutOverride(node, attribute, isInline, slotName);
}
}
and use it for every attribute of the node.
Lastly, create unit tests so for every attribute that can potentially be overriden.
This issue will require at least 3 PRs, namely:
Describe alternatives you've considered
No response
Additional context
No response
Please confirm that you have searched existing issues in the repo
Yes, I have searched the existing issues
Any related issues?
#2463, #1715
What is the area that this feature belongs to?
Testing
Is your feature request related to a problem? Please describe.
There are two issues that arise from #2463 (and I'll be quoting myself):
Inconsistent naming in
NodeProcessor.data.tsThe naming conventions of the test inputs in
NodeProcessor.data.tsare inconsistent. Many of the elements there have a test to check if the slots do override the attributes of the elements, but they are named in two separate ways:PROCESS_[ELEMENT]_ATTRIBUTES_NO_OVERRIDEPROCESS_[ELEMENT]_[ATTRIBUTE]_SLOT_TAKES_PRIORITYI think that's why the author of #2053 wrote another constant called
PROCESS_PANEL_HEADER_SLOT_TAKES_PRIORITYwhen the constantPROCESS_PANEL_ATTRIBUTES_NO_OVERRIDEtests for the exact same thing. That's why I have anexpectstatement after each of these two tests, because in both times the logger is called with the same input.Logger warnings still inconsistent
With the merging of #2053, Panels, Dropdowns, Modals and Popovers print warnings to the console if there are slots overriding the element attributes. However, other elements such as Quizzes and QOptions do not print warnings when this happens. This is because in the code of
MdAttributeRenderer.ts, not every attribute is checked to see if there is an overriding slot, so the logger will not warn if the unchecked attributes are overridden.Describe the solution you'd like
Firstly, standardise the constant names in
NodeProcessor.data.tstoPROCESS_[ELEMENT]_[ATTRIBUTE]_SLOT_TAKES_PRIORITYas it is clearer than the other alternative.To fix the inconsistent logger warnings once and for all, implement this new method
and use it for every attribute of the node.
Lastly, create unit tests so for every attribute that can potentially be overriden.
This issue will require at least 3 PRs, namely:
Describe alternatives you've considered
No response
Additional context
No response