Allow customizer controls to be encapsulated by accepting pre-instantiated settings

[westonruter]

In #35926 the ability to add setting-less controls was made possible. The work here only went halfway, however. Consider wanting to re-use a control in a standalone context (see #29071), where the settings used in the control are just plain wp.customize.Value instances. Controls should allow pre-instantiated Value (Setting) objects to be passed in as params.settings. And when this is done, there would be no api( settingId... ) deferrals.

So one should be able to create a new control like this:

var control = new wp.customize.Control( 'product_name', {
    // ...
    settings: {
        'default': new wp.customize.Value( 'Something' )
    }
} );

Instead of having to do:

wp.customize.create( 'product_name', 'product_name', 'Something', {} );
control = new wp.customize.Control( 'product_name', {
    // ...
    settings: {
        'default': 'product_name'
    }
} );

The goal is to allow controls to be encapsulated and to be able to use them in standalone contexts or embedded inside of other controls.

Related:

• #30738
• #37275
• #29071

Related: #38077 (Facilitating embedding customizer controls outside of sections)

The patch looks like an improvement to me, although I haven't dug into this code before.

The patch for this is being tested and improved by @sayedwp.

As part of this, we should also defer adding the elements with the input/setting links until the setting is actually ready, even if the settings all exist up front. This will ensure that delay embedding their contents (or use content template) until ready will also also work as expected with data-customize-setting-link.

@sayedwp Would you give the latest patch a try?

Sure I will test it today

@westonruter Since the setting less control would not have notifications set by default its throwing error that setting.notifications is undefined, so we probably want to add a condition for control.setupNotifications() ?

I am able to create control using api.DynamicControl using ​wp-customize-posts plugin without any errors however when I try to add a setting less control in other sections, the control is created and I can see that in console but it does not append/render in the section.

Here is the code I tried

(function( api ) {

	api.section.bind( 'add', function( section ) {
		if ( 'colors' === section.id ) {

			var addSettingLessControl = function addSettingLessControl() {
				var control, id = 'product_color';

				control = new api.Control( id, {
					type: 'color',
					params: {
						section: section.id,
						label: "Test Control",
						active: true,
						type: 'color',
						input_attrs: {
							'data-customize-setting-link': id
						},
						settings: {
							'default': new api.Value( '#000000' )
						}
					}
				} );

				api.control.add( control.id, control );
			};

			section.expanded.bind( function( expanded ) {
				if ( expanded ) {
					addSettingLessControl();
				}
			} );
		}
	} );

})( wp.customize );

Am I doing something wrong here?

Tested with "'4.7-alpha-38934'" and twenty-sixteen theme.

Sorry I ran out of time. 😞 We'll have to hit this in 4.8.

@sayedwp Any 4.7 checks you have in feature plugins should be bumped to 4.8.

Per yesterday's bug scrub, we're going to punt this to 4.8.1.

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

The changeset date and status are two examples of controls that would benefit from this.

This should be a follow-up on ​https://github.com/xwp/wordpress-develop/pull/267

Some areas where this can be utilized: https://core.trac.wordpress.org/ticket/42022#comment:10

In 41750:

Customize: Allow controls to be created with pre-instantiated Setting object(s), or even with plain Value object(s).

• Allow passing settings in keyed object (e.g. settings: { default: 'id' } ), or as an array (e.g. settings: [ 'id' ]) with first being default; again, Setting/Value` objects may be supplied instead of IDs.
• Allow a single setting to be supplied with just a single setting param, either a string or a Setting/Value object.
• Update changeset_status and scheduled_changeset_date to be added dynamically with JS and simply passing of api.state() instances as setting.
• Introduce a data-customize-setting-key-link attribute which, unlike data-customize-setting-link, allows passing the setting key (e.g. default) as opposed to the setting ID.
• Allow WP_Customize_Control::get_link() to return data-customize-setting-key-link when setting is not registered.
• Eliminate default_value from WP_Customize_Date_Time_Control since now comes from supplied Value.
• Export status choices as wp.customize.settings.changeset.statusChoices.
• Export date and time formats as wp.customize.settings.dateFormat and wp.customize.settings.timeFormat respectively.

Props westonruter, sayedwp.
See #39896, #30738, #30741, #42083.
Fixes #37964, #36167.