With the WPGraphQL IDE being enqueued by core WPGraphQL, in order to opt-in to "bleeding edge" when the WPGraphQL IDE plugin is active, the plugin should override the enqueueing of scripts to be relative to the plugin and not relative to core.
Initial Proposal (Relative asset path constants)
$path is defined as a relative location for where JS/Style/Asset files are enqueued from (i.e. /wp-graphql/build)
If plugin is active, the $path is overridden with a directory relative to the plugin (i.e. /wpgraphql-ide/build`)
Simply having the WPGraphQL IDE plugin active loads the assets from the plugin instead of from core
These constants could be picked up by core and used to enqueue the assets from the plugin instead of core, and could display the version of the IDE being used.
Problems with this approach
In this approach, the assumption is that all assets will be the same, but just their locations will be different. This is flaky.
If we decide to change names of assets (i.e. we recently changed the main index.js to ide.js and render.js) then the new assets would not be enqueued by core because the relative path isn't the only thing that changed, different files altogether would need to be enqueued.
Perhaps the entire "enqueue_react_app_with_styles" function needs to be a pluggable function or something?
i.e.
public function enqueue_react_app_with_styles(): void {
// if the wpgraphql_ide_enqueue_app function exists, use it to enqueue assets
if ( function_exists( 'wpgraphql_ide_enqueue_app' ) {
wpgraphql_ide_enqueue_app();
return;
}
// else, do default enqueuing
With the WPGraphQL IDE being enqueued by core WPGraphQL, in order to opt-in to "bleeding edge" when the WPGraphQL IDE plugin is active, the plugin should override the enqueueing of scripts to be relative to the plugin and not relative to core.
Initial Proposal (Relative asset path constants)
/wp-graphql/build
)These constants could be picked up by core and used to enqueue the assets from the plugin instead of core, and could display the version of the IDE being used.
Problems with this approach
In this approach, the assumption is that all assets will be the same, but just their locations will be different. This is flaky.
If we decide to change names of assets (i.e. we recently changed the main index.js to
ide.js
andrender.js
) then the new assets would not be enqueued by core because the relative path isn't the only thing that changed, different files altogether would need to be enqueued.Perhaps the entire "enqueue_react_app_with_styles" function needs to be a pluggable function or something?
i.e.