Split up Customizer JS into separate files and remove self-booting jQuery.ready call

[westonruter]

The customize-controls.js file is huge and is named incorrectly now with #28709 and the fleshed-out models for Panels and Sections. The file should be broken up into customize-sections.js, customize-panels.js, and customize-utils.js. The last of which should include the private function exposed as public methods off of wp.customize.utils. This may also include the wp.customize.init() mentioned in #29071. We need to stop booting the Customizer inside of these JS libraries with a direct jQuery.ready call, and instead let the including page invoke that. This is critical for code reusability and for unit testing. For instance, the customize.php page could do in the footer:

<script>
jQuery(function () {
    wp.customize.init( _wpCustomizeSettings );
});
</script>

For wp.customize.utils, see existing patch at: ​https://github.com/xwp/wordpress-develop/pull/47

[celloexpressions]

Per slack, we'll need to patch this right before commit, and are planning on doing this right before beta so that we don't invalidate all outstanding patches on this file.

[ryankienstra]

Here is one way this might be done. I know this will have to wait until right before beta.

This splits customize-controls.js into customize-sections.js, customize-panels.js, and customize-utils.js: ​https://github.com/xwp/wordpress-develop/pull/54

It extracts the initialization into api.init(), located in customize-utils.js.

It also moves the api.Container class to customize-base.js.

[westonruter]

Related: #28510 (Split javascript files in media into modules)

I suggest we hold off on splitting up Customizer JS until the organization of the Media JS is settled on.

[ocean90]

Replying to westonruter:

I suggest we hold off on splitting up Customizer JS until the organization of the Media JS is settled on.

The media split landed in core, see #28510.

[jbpaul17]

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

[westonruter]

See also #40834 (Introduce a JS module pattern to WordPress).

[westonruter]

#38806 was marked as a duplicate.

[westonruter]

I think this makes the most sense to be done as part of a Customizer rewrite, perhaps in a feature plugin powered by the new ​endpoints and making use of React or Vue to power the UI, while naturally maintaining the same Customize JS API.

[celloexpressions]

Replying to westonruter:

I think this makes the most sense to be done as part of a Customizer rewrite, perhaps in a feature plugin powered by the new ​endpoints and making use of React or Vue to power the UI, while naturally maintaining the same Customize JS API.

As long as this is entirely an "internal" rewrite and the JS API remains fully backwards-compatible, I can get behind this idea. That would definitely be the best time to restructure files. I am somewhat skeptical of full backwards compatibility being achievable with such a rewrite, but that's the primary requirement that we would need to consider in such a project.

[westonruter]

Backwards compatibility was maintained when the monolithic Media JS was broken up into separate files.