Parent-Aware Nested Configurators

The flexible relationship of Nested Configurators can be enhanced for speed and ease of use, at the sacrifice of some flexibility.

When to use a parent-aware relationship

In most cases, creating a parent-aware relationship is not necessary. However, reasons you would use these techniques include:

1. To share a complex option filter between parent and child.
   Option filters (with their boolean logic, joins, and large tables of data) can grow in complexity. The more complex the option filter, the more likely it's slower to calculate. If a child configurator needs to use the same option filter data set as its parent, this technique allows that data to be calculated once at the parent level, and then shared across multiple nested configurators without re-calculation. This speeds up the run-time experience.
2. To ensure a child configurator is never launched independently without its parent.
   It's good design to build configurators so they can be launched independently. This keeps the door open to multiple uses of the child (see sidebar below). However, you may have a child configurator which will never be launched without its parent, and in fact will not operate correctly without its parent.
3. To share field values from parent to child more easily and with faster performance.
   Data can always be shared between parent and child configurators using the "from nested...get" and "from nested...set" Snap blocks. However, changing to a parent-aware setup allows
   • simpler Snap code for you to write during design-time, and
   • likely performance gains for your customer during run-time, especially when your child configurator uses parent data many times.
     

Don't forget the benefits of an independent child configurator.
When designing complex configurators using parent/child relationships, we suggest you start by keeping the child configurator independent. Only change to a parent-aware relationship when necessary.

We encourage this independent setup by default because of these benefits:

• Reuse the child configurator within many parents.
  For example, if your company sells cars, then defining the entertainment system as a child configurator allows you to use that same child within many parent car configurators. It's faster to build (and easier to maintain) one nested configurator used across your entire line of cars.
• Launch the child configurator independently, without a parent.
  In this same example, you may want to sell an entertainment system as a spare part, or an after-market option. When launched without a parent, a child configurator will simply use the default values specified in its own fields.

Migrate to a parent-aware architecture described below only if the performance or usability benefits could benefit you.

Creating a Parent-Aware relationship

To move an flexible parent-child configurator relationship into the faster but more limited parent-aware relationship, consider what enhancements you need and enable them.

To share an option filter from parent to child

Option filters streamline your user's experience, but can take time to calculate as they must be refreshed every time a field is changed and the rule cycle runs. If you have an option filter within a parent configurator, and its result set is used by child configurators, you can minimize these re-calculations by making that one refresh (at the parent) available for use by child configurators (sparing un-necessary refreshes within each child).

1. Determine if a single refresh at the parent level is worth sharing among many children. An ideal candidate would be one child configurator used many times by a parent (such as one floor configurator used many times in a building configurator). You can use the debugging and performance tuning techniques to determine this.
2. Open the parent configurator, and find the option filter you want to share.
3. In the advanced section, enable child configurators to reference this option filter by selecting "allow child configurators to reference this option filter"
   

To ensure a child configurator cannot be launched independently

1. Open the child configurator, and select the root UI node to show the configurator properties.
2. In the Nested section, set the configurator to only be used as a nested configurator, and specify the parent. In this screenshot, a configurator named "Child" is set to only be used as a child for the configurator named "Parent"
   

To easily share field values and option filter source data from parent to child

Related topics

1. Ensure the child configurator is set to be used by a specific parent (see the previous section).
2. Once done, Snap rules in this child gain a new Parent category of snap rules. These expose field values from the parent, as well as option filter source data from the parent.
   

• This walkthrough can guide you through creating your first nested configurator and parent configurator, step by step.

• The nested set UI component gives you flexibility in how you want your child configurators to appear, and has examples for your inspiration.
• If your nested configurator contains any output documents, read more here to ensure they are visible and are generated as expected. 
• Using nested configurators adds some steps onto the rule cycle.  You can review all the rule types, and the order in which they are executed (in a stand-alone configurator as well as in a configurator containing nested configurators).
• Measure the run-time performance of your configurators through client-side logging. It's a useful debugging technique.