Overhaul script/style registration and enqueuing process

[boonebgorges]

PressForward currently loads many of its scripts and styles using its AssetsProvider system, which internally uses the Register toolset in Jaxion. The Jaxion system, and PF's technique for leveraging it, have some limitations:

• Assets are not registered (wp_register_script()) separately from their enqueuing (wp_enqueue_script()). Instead, Jaxion expects a 'condition' callback that returns true when the script should appear, and false when it shouldn't. This system requires significant foresight and some potentially complex logic for determining when to return true from 'condition'. PressForward simply errs on the side of loading everything almost everywhere, which is bad for performance.
• Because assets are only registered at the moment of enqueue, it's possible to have a situation like this: Asset A lists asset B as a dependency; on a given page, A's 'condition' returns true, while B's 'condition' returns false; A therefore unexpectedly does not load. As such, this system partly overrides the sanity checks built into WP's dependency system.
• Jaxion expects assets assets to have one of the following types: 'web', 'admin', 'shared'. This requires that we know, at the time of registration, which of these is true, which can lead to some difficult-to-debug situations when a script is loaded in a new location. Moreover, there are certain special cases (such as PF's Nominate This bookmarklet tool) that don't neatly fall into either the 'web' or 'admin' category (because they don't natively fire 'wp_enqueue_scripts' or 'admin_enqueue_scripts').

The current system feels overengineered, raising the bar for developer experience (it's harder to reason about and keep track of), which leads to sacrifices that reduce performance (like PF's just-load-everything strategy).

I'd like to move toward a system that works like this:

• All assets are always registered. There's a couple ways to do this. We could either register assets centrally, as we currently do in Core\Providers\AssetsProvider. This is in the spirit of the current setup. An alternative would be to allow individual components to be responsible for registering their own assets. I don't think it's super important either way. The critical thing is that, instead of maintaining our own registry as Jaxion does, we pass everything immediately to wp_register_script() or wp_register_style().
• Individual components are responsible for enqueuing their own assets, on an as-needed basis. This ensures that we (a) always load the assets when we need them (avoiding cases like #1157), (b) we only load assets when we need them, and (c) we avoid dependency issues like those described above. In addition, this type of system is easier to reason about when doing feature development or troubleshooting: since scripts and styles will generally be enqueued in the same place where the associated markup is built, you'll be able to see that it's happening correctly. There might be some exceptions, as in the case of styles that need to be loaded in the head, where the component will be responsible for hooking into an earlier action to call wp_enqueue_style(), but this would an exception to the rule.

[boonebgorges]

I've got a version of this up and running. I made the primary change at the level of Intraxia\Jaxion\Assets\Register. Instead of register() building an internal queue, and then using that queue to enqueue scripts based on the 'condition' argument, register() now calls wp_register_script(). Assets are then enqueued on an as-needed basis.

I've made very little attempt at this point to pick apart unneeded dependency chains. That being said, I can already see a decrease of 3-5 scripts/styles being added by PF on most pages in the Dashboard. This includes assets that were needlessly loaded globally, as well as those that were loaded on all PF pages but are only needed in a handful of places. I'll continue to clean these areas up as it's convenient to do so.

[boonebgorges]

I'll close this ticket for now, but continue in future versions to look for places where I can improve the relationship between dependent scripts.