fix: CXSPA-13057: deactivated "Add" buttons in product-card after no-attribute-change roundtrip#21727
Open
Uli-Tiger wants to merge 4 commits into
Open
fix: CXSPA-13057: deactivated "Add" buttons in product-card after no-attribute-change roundtrip#21727Uli-Tiger wants to merge 4 commits into
Uli-Tiger wants to merge 4 commits into
Conversation
…attribute-change roundtrip Summary Fixed the CPQ V2 bug where product-card action buttons (Add/Select/Deselect) stayed disabled after a round trip that produced no attribute changes. Root cause The component-level loading$ flag was set to true on user action but only ever reset to false when the attribute component was destroyed and re-created. That re-creation is gated by a deep-equality check in configurator-attribute-composition.directive.ts. With CPQ V2, a no-change round trip returns identical attribute data, so the component is not re-created and loading$ stays true forever. Changes Base components (multi-selection-base, single-selection-base): subscribe to configuratorCommonsService.isConfigurationLoading(owner) and reset loading$ to false when the round trip completes (the store loading flag resets regardless of whether content changed). Added Subscription + ngOnDestroy cleanup. Product card (.ts / .html): introduced disableActions$ (local product-fetch loading OR parent loading$), bound the three action buttons and the quantity control to it, and removed the loading$.next(true) calls from the action handlers so the local flag is no longer left stuck. Immediate feedback is preserved because the parent sets its loading$ synchronously via the emitted event. Tests: added mocks/isConfigurationLoading and new specs covering loading reset and button re-enable after a no-change round trip; added fixture teardown to the three real-store specs to avoid leaked store subscriptions (repo uses destroyAfterEach: false). side-Issue discovered (cause type error in second roundtrip): In configurator-attribute-multi-selection-bundle.component.ts I made both helpers immutable — they build a new array (and a new value object for the changed value) instead of mutating in place: updateMultipleSelectionValues now uses this.multipleSelectionValues.map(...). updateMultipleSelectionValuesQuantity now creates an updatedValue copy instead of value.quantity = ….
…into feature/CXSPA-13057
Contributor
Merge Checks Failed |
spartacus
 |
||||||||||||||||||||||||||||
| Project |
spartacus
|
| Branch Review |
feature/CXSPA-13057
|
| Run status |
|
| Run duration | 04m 18s |
| Commit |
|
| Committer | Ulrich Stellmacher |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
 |
0
|
 |
3
|
 |
0
|
 |
0
|
 |
103
|
| View all changes introduced in this branch ↗︎ | |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Fixed the CPQ V2 bug where product-card action buttons (Add/Select/Deselect) stayed disabled after a round trip that produced no attribute changes.
Root cause
The component-level loading$ flag was set to true on user action but only ever reset to false when the attribute component was destroyed and re-created. That re-creation is gated by a deep-equality check in configurator-attribute-composition.directive.ts. With CPQ V2, a no-change round trip returns identical attribute data, so the component is not re-created and loading$ stays true forever.
Changes
Base components (multi-selection-base, single-selection-base): subscribe to configuratorCommonsService.isConfigurationLoading(owner) and reset loading$ to false when the round trip completes (the store loading flag resets regardless of whether content changed). Added Subscription + ngOnDestroy cleanup.
Product card (.ts / .html): introduced disableActions$ (local product-fetch loading OR parent loading$), bound the three action buttons and the quantity control to it, and removed the loading$.next(true) calls from the action handlers so the local flag is no longer left stuck. Immediate feedback is preserved because the parent sets its loading$ synchronously via the emitted event.
Tests: added mocks/isConfigurationLoading and new specs covering loading reset and button re-enable after a no-change round trip; added fixture teardown to the three real-store specs to avoid leaked store subscriptions (repo uses destroyAfterEach: false).
side-Issue discovered (caused type error in second roundtrip): In configurator-attribute-multi-selection-bundle.component.ts I made both helpers immutable — they build a new array (and a new value object for the changed value) instead of mutating in place:
updateMultipleSelectionValues now uses this.multipleSelectionValues.map(...). updateMultipleSelectionValuesQuantity now creates an updatedValue copy instead of value.quantity = ….