WP_Customize_Manager::register_control_type should also address registering JS subclasses

[celloexpressions]

There are a couple of steps required to leverage JS for custom Customizer controls. In addition to declaring the object, which is basically like subclassing in PHP, you have to extend the Customizer's controlConstructor with the subclass.

It seems like register_control_type() could also take care of this (in addition to printing JS templates for controls), if we added an optional second argument for the JS class name. This would lower the barrier to creating new JS-heavy Customizer controls, and also make the somewhat annoying step of registering the control type more useful.

Essentially, we would be introducing a mechanism to do this automatically:

/**
 * Extends wp.customizer.controlConstructor with control constructors for
 * menu_item, nav_menu, and new_menu.
 */
$.extend( api.controlConstructor, {
        menu_item: api.Menus.MenuItemControl,
        nav_menu: api.Menus.MenuControl,
        new_menu: api.Menus.NewMenuControl
});

[westonruter]

Good idea.

[celloexpressions]

Noting that we should also do the same for custom panel and section types, which currently have the JS API part and will get register_panel|section_type() in #30737.

[westonruter]

I'm not sure of the need for this now. Basically what I think this would look like is adding some JS identifier in the call to register_control_type, for example given a My_Custom_Control PHP class that has a $type of my_custom this ticket would entail doing something like this:

<?php
$wp_customize->register_control_type( 'My_Custom_Control', 'MyCustomPlugin.Control' );

Which would then translate into PHP generating this JS:

wp.customize.controlConstructor[ "my_custom" ] = MyCustomPlugin.Control;

However, we have to enqueue the JS for MyCustomPlugin.Control anyway, so it is just as easy to handle that in the JS file where that is defined to begin with, for example:

wp.customize.controlConstructor.my_custom = ( function() {
    var MyCustomPlugin = wp.customize.Control.extend({ /*...*/ });
    return MyCustomPlugin;
} )();

This is what I've been doing for the past couple years and it works great.