refactor(frontend): avoid redundant validateOperator call in applyOperatorBorder#5702
refactor(frontend): avoid redundant validateOperator call in applyOperatorBorder#5702PG1204 wants to merge 13 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5702 +/- ##
============================================
- Coverage 54.54% 54.40% -0.15%
+ Complexity 3164 2857 -307
============================================
Files 1128 1108 -20
Lines 45753 42773 -2980
Branches 5008 4605 -403
============================================
- Hits 24958 23269 -1689
+ Misses 19362 18149 -1213
+ Partials 1433 1355 -78
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
/request-review @Xiao-zhen-Liu Follow-up for the split-out applyOperatorBorder change: #5626. Includes the test for the "validation passed in" path. |
|
@Xiao-zhen-Liu do you want to check on this one? |
Hi team, any update on this PR? |
|
@Xiao-zhen-Liu Please check this PR. |
Automated Reviewer SuggestionsBased on the
|
Xiao-zhen-Liu
left a comment
There was a problem hiding this comment.
LGTM — clean split-out of the change from #5626, and good call keeping the lazy fallback (the operator-add path has no Validation in hand, so it can't be removed).
What changes were proposed in this PR?
WorkflowEditorComponent.applyOperatorBorder(operatorID)` always recomputes validation as its first step:
This is redundant when the helper is called from the validation-stream subscriber in handleOperatorValidation, the stream's emitted event already carries the Validation result that was just computed by updateValidationState.
This PR:
Originally flagged as an optional nit during the PR #5146 review. Attempted in PR #5626 but split out as per the reviewer's request so that PR could stay scoped to test restructuring; this PR completes the follow-up.
Any related issues, documentation, discussions?
Closes #5683
Related: PR #5146 (where the nit was raised), PR #5626 (where this was attempted and split out).
How was this PR tested?
Added one focused unit test in
workflow-editor.component.spec.tsinside the existingoperator border restoration after navigationdescribe block:it("uses the Validation passed in instead of recomputing it", ...). The test clears thevalidateOperatorspy after the operator-add validation chain settles, then callsapplyOperatorBorderdirectly with aValidationargument and assertsvalidateOperatoris not called.Verified locally:
tsc --noEmit: cleaneslint: cleanng test(jsdom): 26/26 pass in the editor spec (was 25, new test adds one)ng run gui:test-browser: 13/13 passWas this PR authored or co-authored using generative AI tooling?
This PR was co-authored using Claude Code (Anthropic Claude Opus 4.7)