[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                          |  westonruter
 Priority:  high                                 |      Status:  closed
Component:  Customize                            |   Milestone:  4.9
 Severity:  normal                               |     Version:  3.4
 Keywords:  has-patch needs-unit-tests needs-    |  Resolution:  fixed
  dev-note                                       |     Focuses:  javascript
-------------------------------------------------+-------------------------
Description changed by westonruter:

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',
>     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

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_name', {
     // ...
     settings: {
         'default': new wp.customize.Value( 'Something' )
     }
 } );
 }}}

 Instead of having to do:

 {{{#!js
 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

--

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