[wp-trac] [WordPress Trac] #37964: Allow customizer controls to be encapsulated by accepting pre-instantiated settings

[WordPress Trac]

#37964: Allow customizer controls to be encapsulated by accepting pre-instantiated
settings
-------------------------+-------------------------
 Reporter:  westonruter  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.7
Component:  Customize    |     Version:  3.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript
-------------------------+-------------------------
Changes (by westonruter):

 * keywords:   => has-patch


Old description:

> 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:
>
> {{{#!js
> var control = new wp.customize.Control( 'product_color', {
>     type: 'color',
>     params: {
>         settings: {
>             'default': new wp.customize.Value( '#000000' )
>         }
>     }
> } );
> }}}
>
> Instead of having to do:
>
> {{{#!js
> wp.customize.create( 'product_color', 'product_color', settingArgs.value,
> {} );
> control = new wp.customize.Control( 'product_color', {
>     type: 'color',
>     params: {
>         settings: {
>             'default': 'product_color'
>         }
>     }
> } );
> }}}
>
> 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.

New description:

 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:

 {{{#!js
 var control = new wp.customize.Control( 'product_color', {
     type: 'color',
     params: {
         settings: {
             'default': new wp.customize.Value( '#000000' )
         }
     }
 } );
 }}}

 Instead of having to do:

 {{{#!js
 wp.customize.create( 'product_color', 'product_color', '#000000', {} );
 control = new wp.customize.Control( 'product_color', {
     type: 'color',
     params: {
         settings: {
             'default': 'product_color'
         }
     }
 } );
 }}}

 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

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37964#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform