-
Notifications
You must be signed in to change notification settings - Fork 33
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
[FEAT] Remove all overlays of a given bpmn shape element #1186
[FEAT] Remove all overlays of a given bpmn shape element #1186
Conversation
♻️ PR Preview d46e242 has been successfully destroyed since this PR has been closed. 🤖 By surge-preview |
b3c5c27
to
d6e4da2
Compare
d6e4da2
to
face75f
Compare
♻️ PR Preview d46e242 has been successfully destroyed since this PR has been closed. 🤖 By surge-preview |
face75f
to
f854f0d
Compare
9835849
to
c2dd528
Compare
10e699c
to
1065c91
Compare
1065c91
to
63e1afd
Compare
* | ||
* @param bpmnElementId The BPMN id of the element where to remove the overlays | ||
*/ | ||
removeAllOverlays(bpmnElementId: string): void { |
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.
❓ could be just name the method removeOverlays
to prepare #1178 ? to identify which overlays to remove, we will only have to pass an additional optional paramater without having to change the API or add a new method
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 think we could rename it when we do #1178, because for now, we remove only all overlays, and I didn't think about how to implement it.
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.
That's true, we don't know how we are going to implement the removal of specific overlays (we may not implement it soon as well).
So ok to keep this method name but in the TSDoc, can we put an @experimental
annotation and state that this method is subject to name change when will implement #1178? That way we already warn users of a possible breaking change
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.
done in ad12c6f
expectSvgElementClassAttribute(svgGroupElement, HtmlElementLookup.computeClassValue('bpmn-service-task', additionalClasses)); | ||
expectSvgElementClassAttribute(svgGroupElement, HtmlElementLookup.computeClassValue('bpmn-service-task', options?.additionalClasses)); | ||
|
||
const overlayGroupElement = document.querySelector<SVGGElement>(`#${this.bpmnVisualization.graph.container.id} > svg > g > g:nth-child(3) > g[data-bpmn-id="${bpmnId}"]`); |
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 am working on a refactoring PR that moves the query selectors along with other selectors used in tests. Both PR are changing the code, so merge conflicts are going to happen.
Kudos, SonarCloud Quality Gate passed! |
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.
LGTM 👍🏿
Covers #1168