Single Items view
There’s only a single flexible view available in the Items tab. The default view looks similar to Tree View, only the Input Parameters and Calculations panels are in the same part of the screen.
To achieve the Table View like layout, there are more properties to consider. You can find details in Detail Page Layout and Dynamic Tabs.
Table View in Ember
Default Items view in React
Items view in React with defaultPlacement: "bottom"
Items view in React with defaultPlacement: "bottom"+ siderAlwaysWithTabs: truebottom
Items view in React with hideSiderPanel: true
Preferences
Items table
Ember preferences are not used in React for Items table. You need to migrate them manually if you want to keep Ember preferences in React.
Module name | Ember preferences name | React preferences name |
|---|---|---|
Quoting |
|
|
Agreements & Promotions |
|
|
Rebates |
|
|
Result matrix
Result matrix preferences behave a bit differently than in Ember (they follow the behaviour of the Classic UI). There are no preferences by default. If you are missing your preferences for a result matrix, then you need to set up a preferences name in the Groovy logic. Again, if you want to keep the result matrix preferences stored in Ember, you have to migrate them manually, so they are available under a different name.
Preferences name in Ember | Preferences name in React | |
|---|---|---|
No preference name set |
| No preferences displayed |
|
|
|
Data and new endpoints
There’s a new set of endpoints that are used in React: /clicmanager.*. The main difference is that header and line items data are never sent together. We needed this to be able to support thousands of line items. So, for example. /clicmanager.fetchheader and /quotemanager.fetch return similar responses, but the new one has no line items and includes ioMeta to know which inputs and outputs are used by the line items. You can get line items with /clicmanager.fetch that acts as a standard paginated listing.
New endpoints are described in the API documentation.
Persisted vs. temporary data
In “Autosave off” mode (manual save), data is first stored to the temporary objects on the backend first. When the user clicks the Save button, the data is moved from the temporary objects to the persisted objects. Even before the user saves the document for the first time, the data is already stored in the temporary objects. There are different type codes used for the temporary objects compared to the persisted ones (e.g. Q vs. QTMP for quotes). This may affect the Groovy logic in some cases.
api.currentItem() returns a temporary object in “Autosave off” mode.
Be careful with api.find(), you may need to compose and use the “real” typedId instead of the typedId of the temporary data.
In “Autosave off” mode, the line items also have a different type code: QLITMP instead of QLI.
Interceptors
The interceptors used in Ember and React are incompatible. In React, the interceptors have been greatly improved. They can be written by configuration engineers and there is no need to redeploy the application if the new code exists. If you use interceptors in Ember, please contact CSM to coordinate interceptors migration to React.
Documention for the interceptors used in React:
Loops and inline configurators
It’s possible the inline configurators will get to the loop state. There could be more reasons, but it’s usually solvable by adding HIDDEN inputs for attributes that do not represent an input editable by the user. The list of such inputs is displayed in the developer console:
def hiddenInputs = [ "office", "customer", "distributionChannel", "sku", "targetDateLineItem" ]
def ce = api.createConfiguratorEntry()
for (name in hiddenInputs) {
api.inputBuilderFactory()
.createHiddenEntry(name)
.addToConfiguratorEntry(ce)
}
return ce
The next possible reasons for such loops is the input value that is changing every time when the configurator logic is executed, like showing a current timestamp. You either need to make it HIDDEN or remove it.