feat: support plugin registration for the IDE

[jasonbahl]

What this does:

This allows 3rd party plugins to "registerPlugin" to the WPGraphQL IDE.

ex:

help.php

<?php
/**
 * Plugin Name: GraphiQL Help Screen
 * Plugin Author: WPGraphQL
 * Description: Example of how third parties can register plugins that extend the WPGraphQL IDE
 */

namespace WPGraphQLIDE\Plugins\Help;

add_action( 'wpgraphqlide_enqueue_script', __NAMESPACE__ . '\\enqueue_plugin' );

function enqueue_plugin() {

	$asset_file = include WPGRAPHQL_IDE_PLUGIN_DIR_PATH . 'build/help.asset.php';

	wp_enqueue_script(
		'wpgraphql-ide-help-plugin',
		WPGRAPHQL_IDE_PLUGIN_URL . 'build/help.js',
		array_merge( $asset_file['dependencies']),
		$asset_file['version'],
		true
	);

}

help.js

const { registerPlugin } = WPGraphQLIDE;
import { Icon, help } from "@wordpress/icons";

registerPlugin( 'help', {
	title: 'Help',
	icon: () => <Icon icon={help} />,
	content: () => <><h2>This is a 3rd party plugin.</h2></>
})

Would output the following:

---

In fact, you can actually see this example plugin built-in to this PR:

see the ./plugins/help directory!

---

Summary of this PR:

• import @wordpress/icons
• introduce custom webpack config for different entries. This generates different asset.php files
• separate index.js and app.jsx as different entry points. index sets up some re-usable functions that can be used by 3rd party extensions, app renders the app
• define WPGRAPHQL_IDE_PLUGIN_DIR_PATH and WPGRAPHQL_IDE_PLUGIN_DIR_PATH for better re-usability of directory/path definitions
• split the enqueing of the index.js and app.js with the wpgraphqlide_enqueue_script action in between. This allows for the initial "setup" of functions to be enqueued, then extensions to be enqueued, then the app to be enqueued
• add /plugins/ directory with initial README.md
• add initial plugins/help plugin to show how a 3rd party plugin could hook into the GraphiQL IDE
• move the rendering of the App out of index.js into App.jsx
• add "registerPlugin" function to index.js which dispatches to the store to register a plugin
• update Editor.jsx to read "plugins" from the redux store and add them to
• add action/selector/reducer for registering a plugin

[jasonbahl]

@josephfusco I pushed up a new commit cleaning up some things, adding some inline comments, adding a README.md to the help plugin, etc.

Looking forward to any feedback you might have! 🙏🏻

[jasonbahl]

I've ejected into a custom wepback.config.js so that each script can be enqueued seperately.

This allows us to export functions in the index.js and enqueue them to be available in plugins and the app.

Since functions like registerPlugin and the redux store(s) need to be available before plugins and the App call those functions, and we're not importing them via an NPM build script, we need to make sure the enqueue order has the index.js script enqueued first (as a dependency of anything that needs those functions).

[jasonbahl]

now that we have determined names for each of the IDE areas, possibly this could be renamed to something like getActivityBarPlugins instead of just plugins 🤔

[josephfusco]

I agree. Feel free to make that change here if you feel inclined to, otherwise can make a separate issue to scrub the whole codebase for any other possible renames before moving on.

[jasonbahl]

@josephfusco let's follow-up on this.

I think we'll see some other patterns emerge re: naming things, file organization, etc as we start implementing the other "pluggable" areas

[josephfusco]

Clean!

[josephfusco]

This is great work @jasonbahl, and thank you for the comments and included documentation!

We may want to add test coverage to check on the window object structure just to have that explicitly called out for posterity, but since the plugin relies on those things internally, I don't feel it's absolutely critical right now.