feat: CPQ configurator process backed by CPQ 2.0 API (CXSPA-13470)#21556
feat: CPQ configurator process backed by CPQ 2.0 API (CXSPA-13470)#21556Larisa-Staroverova wants to merge 19 commits into
Conversation
spartacus
 |
||||||||||||||||||||||||||||
| Project |
spartacus
|
| Branch Review |
feature/support_cpq_v2
|
| Run status |
|
| Run duration | 04m 19s |
| Commit |
|
| Committer | LarisaStar |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
 |
0
|
 |
3
|
 |
0
|
 |
0
|
 |
101
|
| View all changes introduced in this branch ↗︎ | |
Larisa-Staroverova
changed the title
ChristophHi
left a comment
ChristophHi
left a comment
There was a problem hiding this comment.
The DDLB consisting the possible value behaves strange. The 'de-select' options is rendered twice, in addition the description changes after something has been selected.
| take(1), | ||
| map((currentGroupId) => { | ||
| // Group ids of conflict groups (Configurator.GroupType.CONFLICT_GROUP) always start with 'CONFLICT' | ||
| const applicableCurrentGroupId = |
There was a problem hiding this comment.
I don't see why this change is relevant for CPQ, as we don't have conflict groups. Why is this part of the PR and what exactly does it address?
There was a problem hiding this comment.
This code was refactored because it did not work in conjunction with the conflict solver; specifically, the conflict group ID became unstable during a new round trip in the VCP scenario.
| map((configResponse) => { | ||
| configResponse.owner = owner; | ||
| return configResponse; | ||
| return this.store.pipe( |
There was a problem hiding this comment.
From my pov we should not access the store from an OCC adapter. The enrichment of the configuration with an already existing state should happen in the reducer.
There was a problem hiding this comment.
The intention was to prevent the call to readConfiguration, since CPQ createConfiguration already contains the data for all groups; otherwise, readConfiguration would have been used to retrieve the data for the specific group from the backend. In the VCP case, readConfiguration was to be called as usual.
There was a problem hiding this comment.
A reducer is a pure function that executes after an action has been dispatched. When READ_CONFIGURATION_SUCCESS reaches the reducer, the HTTP request has already been executed (or skipped) by that point. Because reducers are designed to be free of side effects, they cannot initiate, cancel, or prevent network requests. Managing side effects is the responsibility of the effects layer (readConfiguration$, groupChange$) and, in the current implementation, the adapter.
Therefore, if the objective is to prevent readConfiguration from being called for CPQ, that logic must remain in the effect or adapter layer rather than in the reducer.
There was a problem hiding this comment.
That statement is correct. Of course I didn't mean that the reducer would interfere with network requests. Still it is able to merge a new state with an existing one, together with the effects we should be able to avoid adapter calls and fetch data from the existing state
…/configurator-basic.effect.spec.ts Co-authored-by: Christoph Hinssen <33626130+ChristophHi@users.noreply.github.com>
2 participants
No description provided.