## Nitro Grids Validation
Nitro currently provides a mechanism to [validate window grids](https://nitroqa.powerhrg.com/product_rules/window_grid_rules?mt=Window+Grid+Rules) based on product configs. For every window created, Nitro can determine a set of validation rules to be applied to the item based on the product configs selected by the user to customize the window.

In order to determine which validations to apply to a window, Nitro will look for validation rules configured for the following product config selections:

1. **Model** config;
2. **Style** config;
3. **Type** config (refered to as Lite Config): The product config used to restrict validations to windows with a specific number of lites;
4. **Grid Pattern** config: The config that informs which grid pattern was chosen (Colonial vs Queen Ann for instance);
5. Window **Split** config: Config that is present on certain windows and informs the proportions of each lite within the frame.

Here's an example of a set of grid rules for the **height** dimension of a window with a brief examplanation of how it works (target product configs are ommitted for brevity):


**NOTE**: There's a typo on the image above, the number of horizontal bars allowed in the blue condition is 1.

Things to be aware:

1. Window items where the **Grid Pattern** value is **None** won't have grids;
2. Window items that do not include a **Split** configuration, can ignore this condition when looking up validation rules, and the lookup logic should only include **Model**, **Style**, **Type** and **Grid Pattern**;
3. For window items including **Split**, there will be a UX caveat that we need to further discuss: Users can configure grids before they pick the **Split** option in Home Tour, which means grids can be configured before a validation rule is available to be applied by Home Tour. One suggestion is to hide the Grid Details section until the **Split** config is selected by the user.

## Integrating Plan

In order to make Home Tour aware of these rules, we will have to "compile" them into a data structure embedded into the decision tree that can be leverage by Home Tour (client-side only operations).

### The Data Structure

Based on how Nitro associate these rules to product configs, the following data-structure seems to fit our needs:

/**
 * Represents a single validation rule for a given range of dimension (width or height) values.
 */
type GridValidationRule = {
    /**
     * The range of dimension (widht or height) values that triggers this rule.
     */
    range: [number, number]
    /**
     * Maximum number of grid bars allowed within this dimension range of values.
     */
    maxBars: number
    /**
     * Lite numbers to be validated.
     */
    lites: number[]
}

/**
 * Represents a grid validation targeting a set of product config selection.
 */
type GridValidation = {
    /**
     * The list of product config ids that must be selected in order to trigger
     * this grid validation.
     */
    target: number[]
    /**
     * List of all grid validation rules to run against the window's width dimension.
     */
    width: GridValidationRule[]
    /**
     * List of all grid validation rules to run against the window's height dimension.
     */
    height: GridValidationRule[]
}

Here's an example of what the actual data would look like based on the existing validation rules in Nitro:

[
    {
        // `target` in this case translates to the following product configs:
        // Power Symphony - Double Hung - None - Top Sash Only
        target: [778871, 778881, 778981, 789391],
        width: [
            {
                range: [0, 10.25],
                maxBars: 0,
                lites: [1]
            },
            {
                range: [10.25, 23.25],
                maxBars: 1,
                lites: [1]
            },
            // remaining rules omitted
        ],
        height: [
            {
                range: [0, 16],
                maxBars: 0,
                lites: [1]
            },
            {
                range: [16, 42],
                maxBars: 1,
                lites: [1]
            },
            // remaining rules omitted
        ]
    },
    {
        // `target` in this case translates to the following product configs:
        // Power Symphony - Double Hung - None - Both Sashes
        target: [778871, 778881, 778981, 789396],
        width: [
            {
                range: [0, 10.25],
                maxBars: 0,
                lites: [1, 2]
            },
            {
                range: [10.25, 23.25],
                maxBars: 1,
                lites: [1, 2]
            },
            // remaining rules omitted
        ],
        height: [
            {
                range: [0, 16],
                maxBars: 0,
                lites: [1, 2]
            },
            {
                range: [16, 42],
                maxBars: 1,
                lites: [1, 2]
            },
            // remaining rules omitted
        ]
    },
]

The data structure represented above would be enough to allow Home Tour to validate each grid Lite field independently against the current `width` and `height` values set for the window.

### The Work

In order to implement the proposed design, we'd need to tackle four problems:

1. Compile the grid validation rules into the proposed data structure;
2. Attach the new data structure into the windows decision tree so it's available in Home Tour;
3. Implement the front-end logic to interpret and execute these validation rules as grid values are entered by the user;
4. The windows decision tree needs to be re-generated any time these grid validation rules are updated in Nitro.