@configura/web-api 2.2.0-alpha.1 → 2.2.0-alpha.3

package/dist/syncGroups/SyncGroupsHandler.js

@@ -1,370 +1,370 @@
-var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
-    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
-    return new (P || (P = Promise))(function (resolve, reject) {
-        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
-        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
-        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
-        step((generator = generator.apply(thisArg, _arguments || [])).next());
-    });
-};
-import { SelectionType } from "../productConfiguration/CfgFeature.js";
-import { ProductConfigurationBubbleMode, } from "../productConfiguration/CfgOption.js";
-import { SyncGroupsApplyMode } from "./SyncGroupsApplyMode.js";
-import { SyncGroupsPathHelper } from "./SyncGroupsPathHelper.js";
-import { SyncGroupsState } from "./SyncGroupsState.js";
-import { SyncGroupsTransaction } from "./SyncGroupsTransaction.js";
-/* SyncGroup Concepts
- * ==================
- *
- * SyncGroups are a concept in Catalogues that gives the creator the option to attempt to
- * synchronize selections between otherwise independent Features.
- *
- * Each Feature can optionally specify a "Sync Group Code" in the Catalogue. All features with the
- * same sync group code is said to belong to the same Sync Group.
- *
- * In addition, each Feature that is part of a Sync Group should have a "Sync Mode" set which can
- * be either "Read", "Write" or "Read and  Write". The code in the SDK refers to them as "pull",
- * "push" and "twoWay" respectively.
- *
- * The current state of all the SyncGroups is stored in a SyncState. The sync state keeps track of
- * each sync group even if no features are currently visible for that sync group code. In that way,
- * the sync state acts like a kind of short-term memory when a user is configuring a product.
- *
- * The sync state is always discarded when you leave or reload a product and is thus always an
- * empty slate when a product is loaded.
- *
- *
- * Best Effort and Conflicts
- * =========================
- *
- * Catalogues had been along for a long time when the Sync Group functionality was added in 2021,
- * and as a result, it is sort of a layer on top off the normal handling of selecting Options on
- * Features and it is applied in a "best effort"-manner.
- *
- * Two or more Features belonging to the same SyncGroup shows the intent that they should be
- * synchronized, with how being controlled by their respective sync mode.
- *
- * However, the Catalogue format is not strict on how you define the features you want tp keep
- * synchronized. They can for example have only partially overlapping domains (i.e. what Options
- * can be selected) or even no overlap at all which means there is no guarantee that they can
- * always stay in sync.
- *
- * Using different sync modes and bringing features into scope also adds complexity as well as
- * power to create "creative" solutions to design problems.
- *
- * There is also a use case for adding a unique sync group code to single features, which signals
- * the intent that the creator wants those features to keep their previously selected values even
- * when they are not currently visible in the current configuration.
- *
- * In the end, it's up to the Catalogue creator to build the products inside their Catalogues so
- * that his or her intentions are met without unexpected side effects.
- *
- *
- * Technical Details
- * =================
- *
- * Feature types
- * -------------
- *
- * Features can be of three types. (Or that is the model we use in Stage, it seems to hold.)
- *
- * 1. SelectOne Features are like radio buttons, one Option is selected at a time.
- * 2. SelectMany Features ("optional" in Catalogues) are like check boxes, any number of Options
- *    are selected at a time.
- * 3. Group Features ("multiple" in Catalogues) act like a grouping mechanism where all the Options
- *    are permanently selected. No user interaction allowed.
- *
- * Group Features work like any other Feature without SyncGroups. They are just transparent.
- *
- * SelectOne and SelectMany have fully separated sync states. This means that there is never a sync
- * connection between SelectOne and SelectMany Features even if they have the same Sync Group Code.
- *
- * In other words, SelectOne Features only sync with other SelectOne features and vice versa.
- *
- * On what level sync happens is different between SelectOne and SelectMany Features. For SelectOne
- * we store an option code per SyncGroup. For SelectMany we store "On" or "Off" per option code per
- * SyncGroup.
- *
- * You can say that SelectOne is synced on Feature level, and SelectMany is synced on Option level.
- *
- * Note that the same Feature (as in feature code) can exist in multiple places in a configuration
- * tree. In this context, they are treated as individual Features that just happens to have an
- * identical set of settings in the Catalogue.
- *
- *
- * Transactions
- * ------------
- *
- * Selecting an Option in a Feature can trigger a bunch of changes, each of them cascading into new
- * features coming into scope and in turn changing other SyncGroups. As far as the user goes these
- * changes is under the hood and is part of a single change triggered by the first selection.
- *
- * This is also how it is implemented. All the changes created by the initial selection are
- * validated and propagated inside a single "transaction". The transaction is considered complete
- * when the last round of changes did not trigger any new changes in the sync state.
- *
- * In every transaction, each SyncGroup is allowed to be updated only once for SelectOne features or
- * once per unique option code in the case of SelectMany features. This is done to ensure that the
- * propagated changes is guaranteed to stabilize over time and eliminates the risk of loops.
- *
- * Since a Feature can only have a single sync group code, this also means that a Feature will be
- * changed at most once during a single transaction.
- *
- *
- * Applying SyncGroups => Features/Options
- * ---------------------------------------
- *
- * The state of the SyncGroups (as stored in the SyncState) is applied to a Feature/Option under
- * the following conditions:
- * A) The Feature belongs to a SyncGroup, i.e. has a Sync Group Code.
- * B) The feature's sync mode is set to "pull" or "twoWay".
- *
- * ...for SelectOne:
- * C) The SyncState has an option code for this SyncGroup.
- * D) The option code in the SyncState for the SyncGroup is not the Option selected.
- * E) The Feature has an Option with the right option code.
- * F) The Feature has not previously been affected in this transaction, unless it was affected
- *    at Feature initialization.
- *
- * ...for SelectMany (done for every Option):
- * C) The SyncState has a value (on or off) for this SyncGroup and option code.
- * D) The Option is on when it should be off or the other way around.
- * E) The Option has not previously been affected in this transaction.
- *
- * Applying the sync state typically happen when:
- * - A user action on a Feature has changed the SyncState.
- * - Features "comes into scope"
- *
- * A feature "coming into scope" refers features "appearing" during for example a Product load, a
- * parent feature changing selected options to expose new children or an Additional Product coming
- * into scope.
- *
- *
- * Applying Features/Options => SyncGroups
- * ---------------------------------------
- *
- * The Feature/Option is applied to the SyncState under the following conditions:
- * A) The Feature belongs to a SyncGroup, i.e. has a Sync Group Code.
- * B) The feature's sync mode is set to "push" or "twoWay".
- *
- * ...for SelectOne:
- * C) The Option selected is not the option code currently in the SyncState for the SyncGroup.
- * D) The SyncState has not been affected for this SyncGroup in this transaction.
- * E) Any one of the below:
- *    - A user actively selects an Option.
- *    - There is no option code in the SyncState for this SyncGroup.
- *    - The Feature did just come into scope, and the option code in the SyncState for this
- *      SyncGroup is not one of the Options in the Feature. The option code is not in the Feature
- *      Domain for this Feature that is. So, a Feature appearing which cannot take it's selection
- *      from the SyncState will instead write it back.
- *
- * ...for SelectMany (for each Option):
- * C) The SyncState has not been affected for this SyncGroup and option code in this transaction.
- * D) Any one of the below:
- *    - A user actively selects or deselects an Option, and the on or off status differs from what
- *      is in the SyncState for the SyncGroup and option code.
- *    - There is no entry for SyncGroup and option code in the SyncState and the Option is
- *      selected. We only implicitly initialize the SyncState for "on" as there is no way to
- *      explicitly chose what is default of in Catalogues.
- *
- * This typically happens when:
- * - A user selects or deselects an option.
- * - Features comes into scope, like at Product load, a parent feature changing selected options to
- *   expose new children or an Additional Product coming into scope.
- *
- *
- * Implementation Details
- * ======================
- *
- * There are two entry points into the process. One for when a new Product is loaded, when we want
- * to move it into a synced state. The other is when a user selects or deselects an Option.
- *
- * The process can be thought of as a state machine with three states or stages:
- * A) Select/deselect Option and force to SyncState
- * B) Apply the SyncState onto the Product
- * C) Apply the Product onto the SyncState
- *
- * The entry point for a new Product is C. This makes sense as a new Product has no SyncState at
- * all, so applying the Product onto the SyncState is good start.
- *
- * The entry point for user selection is A.
- *
- * Let's look at how we move between states starting with A.
- *
- * State A will apply the selection onto the Option. It will write to the SyncState. It will then
- * transition to state B.
- *
- * State A is only run once for each user interaction, and not at all for Product Load.
- *
- * State B will apply the SyncState onto Features by recursively going through the configuration
- * tree. Once it finds a Feature/Option which should be changed by the state it:
- * - Checks if it can change it (it can't if the belongs to a so far uninitialized SyncGroup) and
- *   if it can then:
- *   - Changes the selection on the Feature.
- *   - Add the parent Product for the Feature to a list of Products for which a validate call
- *     must later be made.
- *   - Stop recursing down this branch as the validation call might actually change the structure
- *     and children in the branch.
- *
- * Once we have recursed the entire tree the result can be either:
- * - There are Products to validate.
- *   Then we do the validations, and once they are done we move back into state B. We run it again
- *   as we did not recurse all the way down the branches that changed value. With each run, we will
- *   get further out on the branches until finally reaching the end.
- * - There are no Products to validate.
- *   This means that there were no Features which we could apply the SyncState onto. We now move
- *   into state C as the selection changes may have brought new Features into scope, Features which
- *   might write to the SyncState.
- *
- * State C will apply Features onto the SyncState. It will recursively go through the configuration
- * tree. When it's done one of two has happened:
- * - There was a write to the SyncState.
- *   We then move back to state B, as this change in the SyncState could open up things in B. For
- *   example a Feature that could not pull from the SyncState before might be able to do that now.
- * - There was no write to the SyncState.
- *   All is calm. We are done. The settling of the SyncState vs configuration is done. Things are
- *   as in sync as they will be. This is the exit.
- *
- *
- * Side Notes
- * ==========
- *
- * _CfgProductInternal, _CfgFeatureInternal and _CfgOptionInternal are used in Sets and Maps in the
- * code. These objects are only created once for the data they represent. That is, even if a Feature
- * goes in or out of scope the object is the same. This is not true for their wrapper classer
- * CfgProduct, CfgFeature and CfgOption. Those are frequently replaced while running.
- *
- */
-/**
- * Send to root for the passed option and any sibling which is selected, provided the Feature
- * is SelectOne. (As that one (should only be one) can be assumed to be affected).
- */
-function notifyOptionAndSelectedSiblings(option) {
-    return __awaiter(this, void 0, void 0, function* () {
-        const committed = false;
-        const parentFeature = option.parent;
-        if (parentFeature.selectionType === SelectionType.SelectOne) {
-            // These only need to be OneLevel, as the final is ToRoot and they share their parent.
-            yield Promise.all(option.parent.selectedOptions.map((o) => parentFeature._childHasChanged(o._internal, ProductConfigurationBubbleMode.OneLevel, committed)));
-        }
-        yield parentFeature._childHasChanged(option, ProductConfigurationBubbleMode.ToRoot, committed);
-    });
-}
-/**
- * Is used to apply the SyncGroups functionality on the Configuration and the other way around.
- * It also keeps the SyncState.
- */
-export class SyncGroupsHandler {
-    constructor(_syncState, updateMode, _loadingObservable) {
-        this._syncState = _syncState;
-        this.updateMode = updateMode;
-        this._loadingObservable = _loadingObservable;
-    }
-    /**
-     * @param verboseLogging Set to true to get verbose sync state changes logged to the console.
-     */
-    static make(updateMode = SyncGroupsApplyMode.Strict, loadingObservable, initial, verboseLogging = false) {
-        return new SyncGroupsHandler(new SyncGroupsState(verboseLogging, initial), updateMode, loadingObservable);
-    }
-    /** Please note that clones will use the same loadingObservable as their source. */
-    clone() {
-        return new SyncGroupsHandler(this._syncState.clone(), this.updateMode, this._loadingObservable);
-    }
-    getCompactSyncGroupState() {
-        return this._syncState.getCompact();
-    }
-    /** Overwrites the sync state */
-    setCompactSyncGroupState(s) {
-        this._syncState.setCompact(s);
-    }
-    get verboseLogging() {
-        return this._syncState.verboseLogging;
-    }
-    set verboseLogging(v) {
-        this._syncState.verboseLogging = v;
-    }
-    /**
-     * Used to initially apply the sync state onto a new product so that it is "in sync"
-     * and to reapply the sync state when an optional additional product is selected.
-     */
-    init(product, productLoader) {
-        return __awaiter(this, void 0, void 0, function* () {
-            const transaction = yield this.newTransaction(product, productLoader, true);
-            try {
-                yield transaction.applyRootProduct();
-                yield this.commitTransaction(transaction);
-            }
-            finally {
-                this.closeTransaction(transaction);
-            }
-        });
-    }
-    /**
-     * Used when an Option is selected or deselected to apply all consequences of the sync groups.
-     * Can cause multiple extra validation calls to the server.
-     */
-    selectOption(product, option, on, productLoader) {
-        return __awaiter(this, void 0, void 0, function* () {
-            if (product.parent !== undefined) {
-                console.info("Normally the product passed shall be the root product");
-            }
-            yield this.setPending(option);
-            const transaction = yield this.newTransaction(product, productLoader, false);
-            try {
-                const change = yield transaction.selectOption(SyncGroupsPathHelper.getPath(option), on);
-                // Always commit the transaction. The change-result above only tells if the
-                // configuration has changed. The SyncState may however also have changed.
-                yield this.commitTransaction(transaction);
-                return change;
-            }
-            finally {
-                if (this._pending === option) {
-                    yield this.setPending(undefined);
-                }
-                this.closeTransaction(transaction);
-            }
-        });
-    }
-    setPending(newPending) {
-        return __awaiter(this, void 0, void 0, function* () {
-            const oldPending = this._pending;
-            this._pending = newPending;
-            if (oldPending !== undefined) {
-                yield notifyOptionAndSelectedSiblings(oldPending);
-            }
-            if (newPending !== undefined) {
-                yield notifyOptionAndSelectedSiblings(newPending);
-            }
-        });
-    }
-    get pending() {
-        return this._pending;
-    }
-    newTransaction(product, productLoader, assumeNoStartProductState) {
-        var _a;
-        return __awaiter(this, void 0, void 0, function* () {
-            if (this._currentTransaction !== undefined) {
-                this.closeTransaction(this._currentTransaction);
-            }
-            const transaction = yield SyncGroupsTransaction.make(this._syncState, this.updateMode, product, productLoader, assumeNoStartProductState);
-            this._currentTransaction = transaction;
-            // The transaction object is used as loading token
-            (_a = this._loadingObservable) === null || _a === void 0 ? void 0 : _a.startChildLoading(transaction);
-            return transaction;
-        });
-    }
-    closeTransaction(transaction) {
-        var _a;
-        transaction.close();
-        (_a = this._loadingObservable) === null || _a === void 0 ? void 0 : _a.stopChildLoading(transaction);
-    }
-    commitTransaction(transaction) {
-        return __awaiter(this, void 0, void 0, function* () {
-            if (transaction.isClosed) {
-                return;
-            }
-            yield transaction.commit();
-            this.closeTransaction(transaction);
-        });
-    }
-}
+var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
+    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
+    return new (P || (P = Promise))(function (resolve, reject) {
+        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
+        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
+        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
+        step((generator = generator.apply(thisArg, _arguments || [])).next());
+    });
+};
+import { SelectionType } from "../productConfiguration/CfgFeature.js";
+import { ProductConfigurationBubbleMode, } from "../productConfiguration/CfgOption.js";
+import { SyncGroupsApplyMode } from "./SyncGroupsApplyMode.js";
+import { SyncGroupsPathHelper } from "./SyncGroupsPathHelper.js";
+import { SyncGroupsState } from "./SyncGroupsState.js";
+import { SyncGroupsTransaction } from "./SyncGroupsTransaction.js";
+/* SyncGroup Concepts
+ * ==================
+ *
+ * SyncGroups are a concept in Catalogues that gives the creator the option to attempt to
+ * synchronize selections between otherwise independent Features.
+ *
+ * Each Feature can optionally specify a "Sync Group Code" in the Catalogue. All features with the
+ * same sync group code is said to belong to the same Sync Group.
+ *
+ * In addition, each Feature that is part of a Sync Group should have a "Sync Mode" set which can
+ * be either "Read", "Write" or "Read and  Write". The code in the SDK refers to them as "pull",
+ * "push" and "twoWay" respectively.
+ *
+ * The current state of all the SyncGroups is stored in a SyncState. The sync state keeps track of
+ * each sync group even if no features are currently visible for that sync group code. In that way,
+ * the sync state acts like a kind of short-term memory when a user is configuring a product.
+ *
+ * The sync state is always discarded when you leave or reload a product and is thus always an
+ * empty slate when a product is loaded.
+ *
+ *
+ * Best Effort and Conflicts
+ * =========================
+ *
+ * Catalogues had been along for a long time when the Sync Group functionality was added in 2021,
+ * and as a result, it is sort of a layer on top off the normal handling of selecting Options on
+ * Features and it is applied in a "best effort"-manner.
+ *
+ * Two or more Features belonging to the same SyncGroup shows the intent that they should be
+ * synchronized, with how being controlled by their respective sync mode.
+ *
+ * However, the Catalogue format is not strict on how you define the features you want tp keep
+ * synchronized. They can for example have only partially overlapping domains (i.e. what Options
+ * can be selected) or even no overlap at all which means there is no guarantee that they can
+ * always stay in sync.
+ *
+ * Using different sync modes and bringing features into scope also adds complexity as well as
+ * power to create "creative" solutions to design problems.
+ *
+ * There is also a use case for adding a unique sync group code to single features, which signals
+ * the intent that the creator wants those features to keep their previously selected values even
+ * when they are not currently visible in the current configuration.
+ *
+ * In the end, it's up to the Catalogue creator to build the products inside their Catalogues so
+ * that his or her intentions are met without unexpected side effects.
+ *
+ *
+ * Technical Details
+ * =================
+ *
+ * Feature types
+ * -------------
+ *
+ * Features can be of three types. (Or that is the model we use in Stage, it seems to hold.)
+ *
+ * 1. SelectOne Features are like radio buttons, one Option is selected at a time.
+ * 2. SelectMany Features ("optional" in Catalogues) are like check boxes, any number of Options
+ *    are selected at a time.
+ * 3. Group Features ("multiple" in Catalogues) act like a grouping mechanism where all the Options
+ *    are permanently selected. No user interaction allowed.
+ *
+ * Group Features work like any other Feature without SyncGroups. They are just transparent.
+ *
+ * SelectOne and SelectMany have fully separated sync states. This means that there is never a sync
+ * connection between SelectOne and SelectMany Features even if they have the same Sync Group Code.
+ *
+ * In other words, SelectOne Features only sync with other SelectOne features and vice versa.
+ *
+ * On what level sync happens is different between SelectOne and SelectMany Features. For SelectOne
+ * we store an option code per SyncGroup. For SelectMany we store "On" or "Off" per option code per
+ * SyncGroup.
+ *
+ * You can say that SelectOne is synced on Feature level, and SelectMany is synced on Option level.
+ *
+ * Note that the same Feature (as in feature code) can exist in multiple places in a configuration
+ * tree. In this context, they are treated as individual Features that just happens to have an
+ * identical set of settings in the Catalogue.
+ *
+ *
+ * Transactions
+ * ------------
+ *
+ * Selecting an Option in a Feature can trigger a bunch of changes, each of them cascading into new
+ * features coming into scope and in turn changing other SyncGroups. As far as the user goes these
+ * changes is under the hood and is part of a single change triggered by the first selection.
+ *
+ * This is also how it is implemented. All the changes created by the initial selection are
+ * validated and propagated inside a single "transaction". The transaction is considered complete
+ * when the last round of changes did not trigger any new changes in the sync state.
+ *
+ * In every transaction, each SyncGroup is allowed to be updated only once for SelectOne features or
+ * once per unique option code in the case of SelectMany features. This is done to ensure that the
+ * propagated changes is guaranteed to stabilize over time and eliminates the risk of loops.
+ *
+ * Since a Feature can only have a single sync group code, this also means that a Feature will be
+ * changed at most once during a single transaction.
+ *
+ *
+ * Applying SyncGroups => Features/Options
+ * ---------------------------------------
+ *
+ * The state of the SyncGroups (as stored in the SyncState) is applied to a Feature/Option under
+ * the following conditions:
+ * A) The Feature belongs to a SyncGroup, i.e. has a Sync Group Code.
+ * B) The feature's sync mode is set to "pull" or "twoWay".
+ *
+ * ...for SelectOne:
+ * C) The SyncState has an option code for this SyncGroup.
+ * D) The option code in the SyncState for the SyncGroup is not the Option selected.
+ * E) The Feature has an Option with the right option code.
+ * F) The Feature has not previously been affected in this transaction, unless it was affected
+ *    at Feature initialization.
+ *
+ * ...for SelectMany (done for every Option):
+ * C) The SyncState has a value (on or off) for this SyncGroup and option code.
+ * D) The Option is on when it should be off or the other way around.
+ * E) The Option has not previously been affected in this transaction.
+ *
+ * Applying the sync state typically happen when:
+ * - A user action on a Feature has changed the SyncState.
+ * - Features "comes into scope"
+ *
+ * A feature "coming into scope" refers features "appearing" during for example a Product load, a
+ * parent feature changing selected options to expose new children or an Additional Product coming
+ * into scope.
+ *
+ *
+ * Applying Features/Options => SyncGroups
+ * ---------------------------------------
+ *
+ * The Feature/Option is applied to the SyncState under the following conditions:
+ * A) The Feature belongs to a SyncGroup, i.e. has a Sync Group Code.
+ * B) The feature's sync mode is set to "push" or "twoWay".
+ *
+ * ...for SelectOne:
+ * C) The Option selected is not the option code currently in the SyncState for the SyncGroup.
+ * D) The SyncState has not been affected for this SyncGroup in this transaction.
+ * E) Any one of the below:
+ *    - A user actively selects an Option.
+ *    - There is no option code in the SyncState for this SyncGroup.
+ *    - The Feature did just come into scope, and the option code in the SyncState for this
+ *      SyncGroup is not one of the Options in the Feature. The option code is not in the Feature
+ *      Domain for this Feature that is. So, a Feature appearing which cannot take it's selection
+ *      from the SyncState will instead write it back.
+ *
+ * ...for SelectMany (for each Option):
+ * C) The SyncState has not been affected for this SyncGroup and option code in this transaction.
+ * D) Any one of the below:
+ *    - A user actively selects or deselects an Option, and the on or off status differs from what
+ *      is in the SyncState for the SyncGroup and option code.
+ *    - There is no entry for SyncGroup and option code in the SyncState and the Option is
+ *      selected. We only implicitly initialize the SyncState for "on" as there is no way to
+ *      explicitly chose what is default of in Catalogues.
+ *
+ * This typically happens when:
+ * - A user selects or deselects an option.
+ * - Features comes into scope, like at Product load, a parent feature changing selected options to
+ *   expose new children or an Additional Product coming into scope.
+ *
+ *
+ * Implementation Details
+ * ======================
+ *
+ * There are two entry points into the process. One for when a new Product is loaded, when we want
+ * to move it into a synced state. The other is when a user selects or deselects an Option.
+ *
+ * The process can be thought of as a state machine with three states or stages:
+ * A) Select/deselect Option and force to SyncState
+ * B) Apply the SyncState onto the Product
+ * C) Apply the Product onto the SyncState
+ *
+ * The entry point for a new Product is C. This makes sense as a new Product has no SyncState at
+ * all, so applying the Product onto the SyncState is good start.
+ *
+ * The entry point for user selection is A.
+ *
+ * Let's look at how we move between states starting with A.
+ *
+ * State A will apply the selection onto the Option. It will write to the SyncState. It will then
+ * transition to state B.
+ *
+ * State A is only run once for each user interaction, and not at all for Product Load.
+ *
+ * State B will apply the SyncState onto Features by recursively going through the configuration
+ * tree. Once it finds a Feature/Option which should be changed by the state it:
+ * - Checks if it can change it (it can't if the belongs to a so far uninitialized SyncGroup) and
+ *   if it can then:
+ *   - Changes the selection on the Feature.
+ *   - Add the parent Product for the Feature to a list of Products for which a validate call
+ *     must later be made.
+ *   - Stop recursing down this branch as the validation call might actually change the structure
+ *     and children in the branch.
+ *
+ * Once we have recursed the entire tree the result can be either:
+ * - There are Products to validate.
+ *   Then we do the validations, and once they are done we move back into state B. We run it again
+ *   as we did not recurse all the way down the branches that changed value. With each run, we will
+ *   get further out on the branches until finally reaching the end.
+ * - There are no Products to validate.
+ *   This means that there were no Features which we could apply the SyncState onto. We now move
+ *   into state C as the selection changes may have brought new Features into scope, Features which
+ *   might write to the SyncState.
+ *
+ * State C will apply Features onto the SyncState. It will recursively go through the configuration
+ * tree. When it's done one of two has happened:
+ * - There was a write to the SyncState.
+ *   We then move back to state B, as this change in the SyncState could open up things in B. For
+ *   example a Feature that could not pull from the SyncState before might be able to do that now.
+ * - There was no write to the SyncState.
+ *   All is calm. We are done. The settling of the SyncState vs configuration is done. Things are
+ *   as in sync as they will be. This is the exit.
+ *
+ *
+ * Side Notes
+ * ==========
+ *
+ * _CfgProductInternal, _CfgFeatureInternal and _CfgOptionInternal are used in Sets and Maps in the
+ * code. These objects are only created once for the data they represent. That is, even if a Feature
+ * goes in or out of scope the object is the same. This is not true for their wrapper classer
+ * CfgProduct, CfgFeature and CfgOption. Those are frequently replaced while running.
+ *
+ */
+/**
+ * Send to root for the passed option and any sibling which is selected, provided the Feature
+ * is SelectOne. (As that one (should only be one) can be assumed to be affected).
+ */
+function notifyOptionAndSelectedSiblings(option) {
+    return __awaiter(this, void 0, void 0, function* () {
+        const committed = false;
+        const parentFeature = option.parent;
+        if (parentFeature.selectionType === SelectionType.SelectOne) {
+            // These only need to be OneLevel, as the final is ToRoot and they share their parent.
+            yield Promise.all(option.parent.selectedOptions.map((o) => parentFeature._childHasChanged(o._internal, ProductConfigurationBubbleMode.OneLevel, committed)));
+        }
+        yield parentFeature._childHasChanged(option, ProductConfigurationBubbleMode.ToRoot, committed);
+    });
+}
+/**
+ * Is used to apply the SyncGroups functionality on the Configuration and the other way around.
+ * It also keeps the SyncState.
+ */
+export class SyncGroupsHandler {
+    constructor(_syncState, updateMode, _loadingObservable) {
+        this._syncState = _syncState;
+        this.updateMode = updateMode;
+        this._loadingObservable = _loadingObservable;
+    }
+    /**
+     * @param verboseLogging Set to true to get verbose sync state changes logged to the console.
+     */
+    static make(updateMode = SyncGroupsApplyMode.Strict, loadingObservable, initial, verboseLogging = false) {
+        return new SyncGroupsHandler(new SyncGroupsState(verboseLogging, initial), updateMode, loadingObservable);
+    }
+    /** Please note that clones will use the same loadingObservable as their source. */
+    clone() {
+        return new SyncGroupsHandler(this._syncState.clone(), this.updateMode, this._loadingObservable);
+    }
+    getCompactSyncGroupState() {
+        return this._syncState.getCompact();
+    }
+    /** Overwrites the sync state */
+    setCompactSyncGroupState(s) {
+        this._syncState.setCompact(s);
+    }
+    get verboseLogging() {
+        return this._syncState.verboseLogging;
+    }
+    set verboseLogging(v) {
+        this._syncState.verboseLogging = v;
+    }
+    /**
+     * Used to initially apply the sync state onto a new product so that it is "in sync"
+     * and to reapply the sync state when an optional additional product is selected.
+     */
+    init(product, productLoader) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const transaction = yield this.newTransaction(product, productLoader, true);
+            try {
+                yield transaction.applyRootProduct();
+                yield this.commitTransaction(transaction);
+            }
+            finally {
+                this.closeTransaction(transaction);
+            }
+        });
+    }
+    /**
+     * Used when an Option is selected or deselected to apply all consequences of the sync groups.
+     * Can cause multiple extra validation calls to the server.
+     */
+    selectOption(product, option, on, productLoader) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (product.parent !== undefined) {
+                console.info("Normally the product passed shall be the root product");
+            }
+            yield this.setPending(option);
+            const transaction = yield this.newTransaction(product, productLoader, false);
+            try {
+                const change = yield transaction.selectOption(SyncGroupsPathHelper.getPath(option), on);
+                // Always commit the transaction. The change-result above only tells if the
+                // configuration has changed. The SyncState may however also have changed.
+                yield this.commitTransaction(transaction);
+                return change;
+            }
+            finally {
+                if (this._pending === option) {
+                    yield this.setPending(undefined);
+                }
+                this.closeTransaction(transaction);
+            }
+        });
+    }
+    setPending(newPending) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const oldPending = this._pending;
+            this._pending = newPending;
+            if (oldPending !== undefined) {
+                yield notifyOptionAndSelectedSiblings(oldPending);
+            }
+            if (newPending !== undefined) {
+                yield notifyOptionAndSelectedSiblings(newPending);
+            }
+        });
+    }
+    get pending() {
+        return this._pending;
+    }
+    newTransaction(product, productLoader, assumeNoStartProductState) {
+        var _a;
+        return __awaiter(this, void 0, void 0, function* () {
+            if (this._currentTransaction !== undefined) {
+                this.closeTransaction(this._currentTransaction);
+            }
+            const transaction = yield SyncGroupsTransaction.make(this._syncState, this.updateMode, product, productLoader, assumeNoStartProductState);
+            this._currentTransaction = transaction;
+            // The transaction object is used as loading token
+            (_a = this._loadingObservable) === null || _a === void 0 ? void 0 : _a.startChildLoading(transaction);
+            return transaction;
+        });
+    }
+    closeTransaction(transaction) {
+        var _a;
+        transaction.close();
+        (_a = this._loadingObservable) === null || _a === void 0 ? void 0 : _a.stopChildLoading(transaction);
+    }
+    commitTransaction(transaction) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (transaction.isClosed) {
+                return;
+            }
+            yield transaction.commit();
+            this.closeTransaction(transaction);
+        });
+    }
+}