[Experimental] Add super rudimentary support for plugins

[gcorne]

At WordCamp US, there has been some discussion around the potential for Calypso to support plugins. This PR is just a quick example that illustrates how the code chunking and dynamic route definition could be utilized to make it possible for plugins to add routes.

The basic idea is that plugins are a directory in a top-level plugins directory. In this form, the plugin is a section, which while neat isn't ideal long-term because there will need to be a need for both the ability to define new sections and for code to be loaded elsewhere so that the route can be linked to from elsewhere via some way of hooking in.

[mtias]

Thanks for starting this :)

---

A parallel improvement we discussed is also absorbing some of the description of a section — has sidebar, under which top level section it lives (my-sites, reader, me...), the ability to add a sidebar item declaratively, etc — in the sections.js definition. It would reduce the context.layout.state manual manipulations and become more extensible.

[scruffian]

\o/

[johnHackworth]

As I said in previous conversations on the matter, I kind of think it would be a good idea to have some standard method to allow plugins to monkey-patch our own 'internal' components. Like, for example, having a package.json in the plugin folder declaring overwrites or any similar method:

Example:
"ASCII Ratings Plugin"

package.json

{
    "name": "ascii-ratings",
    "version": 1,
    "patches": [
        "components/rating": "./rating-ascii.js"
    ],
    "includes": [
        // files to be included that declares whole new components, helpers, etc
    ],
    "styles": [
        "./ratings-ascii.css"
    ]
}

rating-ascii.js:

export default {
    getStars: function() {
        let stars = '';
        for ( let i = 0; i < Math.ceil( this.props.rating / 10 ); i++) {
            stars += '*';
        }
        return stars;
    }
}

The package.json would tell our build process that it should take the plugin rating-ascii export, and apply everyone of its method to each instance of components/rating. With this example, for example, the plugin would replace our regular gridicon stars in the rating component with ascii *.

Also, it will probably encourage us to write much more modular components (no more 50 lines render methods, since we would want to make them easy to extend and rewrite)

It may sound risky... but it isn't much different of what current php plugins are doing with php admin ...

[gcorne]

As I said in previous conversations on the matter, I kind of think it would be a good idea to have some standard method to allow plugins to monkey-patch our own 'internal' components.

Monkey patching definitely has had a role in the history of JavaScript, but I think it might be interesting to take a page from React and try to come up with guard rails that help developers fall into the pit of success. In terms of being able to make it possible to replace a component with another, I think some sort of <Pluggable /> component might be interesting that helped establish a clear contract between Calypso and the plugin. It might also be interesting to think about how data specs could be established so that certain guarantees can be made. The <Pluggable /> component could also include a try/catch wrapper to make the application more resilient to errors that occur in the plugin that could break the rendering.

[gcorne]

I definitely agree with @johnHackworth that the configuration for the plugin should be part of the plugin and not the configuration file since that will be required in order to make it possible to distribute the plugin. The first step actually may actually be thinking about how Calypso is distributed for general use, which probably means publishing to npm. If wp-calypso is published to npm, then the question becomes what does the developer do to install, run, and configure Calypso. How do they install third-party plugins? How do they write their own that are not intended for distribution? What do they need to be able to actually run Calypso using OAuth?

[artpi]

How about distributing plugins via npm ?

As it comes to monkey-patching, I think we should adopt something similar to hooks and actions.
Provide a limited amount of "entry points" for people to hook into and then see how they are using it.

[lancewillett]

Closing for now since no activity in 6 months — feel free to re-open and continue discussing when the time allows or interest picks back up.