We can extend the plugin interface in a backward compatible way to support several application phases:
-
Support app.initialize(). Once all plugins are loaded, the initialize method can be called. This method will in turn call every plugin which returned a method called initialize from its construction function. The method can return a promise.
-
Support app.terminate(). Similar to initialize but it will shut all plugins down. Analogously to initialize it will call a termination method on all plugins that have one
My main doubt about this design is how to make it clear which things go where, especially the config vs initialization phases. Perhaps we could support passing an object to load() in addition to a function - if an object is passed, it has to at least have an initialize method (that can return a promise), and it can optionally have a configuration getter that returns the env variables specs (once loaded it will be replaced with a cached property) as well as a terminate method (that can return a promise)
We can extend the plugin interface in a backward compatible way to support several application phases:
Support
app.initialize(). Once all plugins are loaded, the initialize method can be called. This method will in turn call every plugin which returned a method calledinitializefrom its construction function. The method can return a promise.Support
app.terminate(). Similar to initialize but it will shut all plugins down. Analogously to initialize it will call a termination method on all plugins that have oneMy main doubt about this design is how to make it clear which things go where, especially the config vs initialization phases. Perhaps we could support passing an object to
load()in addition to a function - if an object is passed, it has to at least have aninitializemethod (that can return a promise), and it can optionally have aconfigurationgetter that returns the env variables specs (once loaded it will be replaced with a cached property) as well as aterminatemethod (that can return a promise)