Improve handling of active state for dynamically-created controls/sections/panels

[westonruter]

When a control, section, or panel is dynamically created in JS and doesn't have a corresponding construct that gets created in PHP, then when the preview refreshes the construct won't be included among the activeControls, activeSections, or activePanels and so it will get its active state set to false. A workaround as used for nav menu items is to define control.active.validate to override whatever is being sent from the preview:

control.active.validate = function() {
        var value, section = api.section( control.section() );
        if ( section ) {
                value = section.active();
        } else {
                value = false;
        }
        return value;
};

The problematic code in Core is:

var active = !! ( activeConstructs && activeConstructs[ id ] );

This is not ideal, and it means that a plugin cannot programmatically do control.active.set( false ).

As suggested in an ​issue on Customize Posts, we could improve the situation by discontinuing from considering constructs that are absent in the preview when determining whether to change the active state, which would specifically be for any constructs that are dynamically created:

var active, isDynamicallyCreated;
if ( ! _.isUndefined( activeConstructs[ id ] ) {
    active = _.isUndefined( activeConstructs[ id ];
} else {
    isDynamicallyCreated = ! _.isUndefined( wp.customize.settings[ type + 's' ][ id ] );
    active = isDynamicallyCreated ? null : false;
}
if ( _.isBoolean( active ) ) {
...

Contextual controls were introduced in #27993 with contextual sections/panels in #29758.

[sayedwp]

Prevents dynamically created constructs from getting deactivated.

[sayedwp]

@westonruter Can we do it more simply like this

var isDynamicallyCreated = _.isUndefined( wp.customize.settings[ type + 's' ][ id ] ),
    active = ! _.isUndefined( activeConstructs[ id ] );

if ( ! isDynamicallyCreated ) {
   if ( active ) {
     construct.activate();
   } else {
     construct.deactivate();
   }
}

[westonruter]

@sayedwp that does look good!

[westonruter]

In 38464:

Customize: Improve handling of active state for dynamically-created controls/sections/panels.

When a customizer construct (panel, section, control) is not added in PHP, the JS has interpreted this to mean that a given construct should be deactivated (because it is gone). This is problematic for dynamically-created constructs in JS, as it has meant that the construct would also have to be created in PHP to ensure the active callback is called, or else a hack would be required to add a construct.active.validate = function() { return true }; to forcibly prevent the construct from getting deactivated.

These workarounds can be eliminated by treating constructs differently when they are created dynamically in JS (after page load) as opposed to being created statically in PHP (on the server). Namely, if a construct is dynamically-created then its absence in a preview refresh should not signal that the construct should be deactivated. Rather, a dynamic construct should only have its activation state toggled if it has a corresponding construct created in PHP when the preview refreshes to explicitly indicate its active state. Otherwise, the management of the active state for a construct created in JS should also be the responsibility of client-side code.

Props westonruter, sayedwp.
Fixes #37270.

[westonruter]

Example code which can be eliminated once this is released: ​https://github.com/xwp/wp-customize-posts/pull/235/files