Interdependencies of plugins

[rajgoel]

Some plugin functionality can only be realised after other plugins have completed their job. For example, the menu-plugin requires that the markdown plugin has created all the slides. In general, there are many use cases where some plugins load dynamic content, and others work on formatting the dynamically generated content.

When initializing we can use promises, to execute stuff after plugins have completed their job, but currently it is not possible to chain this functionality as Reveal.registerPlugin doesn't use promises.

The menu plugin and some of my plugins use a work around specifcally for the markdown-plugin like this:

function createSlideMenu() {
   if (
          !document.querySelector(
            'section[data-markdown]:not([data-markdown-parsed])'
          )
        ) {
    // ...
  } else {
      // wait for markdown to be loaded and parsed
      setTimeout(createSlideMenu, 100);
  }

Obviously, this is a hack and not a clean solution. It would be really nice if one could do something like this:

Reveal.initialize( { plugins: [ RevealMarkdown ] } ).then(() => {
  Reveal.addPlugin( RevealHiglight ).then(() => {
    Reveal.addPlugin( SomeOtherPluginThatRequiresMarkdownAndHighlighToBeCompleted ).then(() => {
       // ...
    });
  });
});

This way inter-plugin dependencies could be cleanly considered.

[hakimel]

Good feedback thanks. I'd love to make this more streamlined.

Plugins are currently loaded and initialized serially in the order they appear in the plugins array. For example the following will wait for RevealMarkdown to finish initializing before moving on to RevealHighlight and finally PluginThatRequiresMarkdownAndHighlight.

Reveal.initialize({
  plugins: [
    RevealMarkdown, 
    RevealHighlight, 
    PluginThatRequiresMarkdownAndHighlight 
  ]
}).then(() => {});

To make this more flexible maybe we can introduce a requires (dependsOn?) field to plugins. That way reveal.js could figure out the correct init order without relying on the plugins array order. Something like this:

const PluginA = {
  id: 'plugin-a',
  requires: [ 'plugin-c' ],
  init: () => () // initialized after PluginC
}

const PluginB = {
  id: 'plugin-b',
  init: () => () // initialized immediately without waiting
}

const PluginC = {
  id: 'plugin-c',
  requires: [ 'markdown' ],
  init: () => () // initialized after RevealMarkdown
}

Reveal.initialize({
  plugins: [ PluginA, PluginB, PluginC, RevealMarkdown ]
});

[Martinomagnifico]

Hi Asvin, good idea to start this discussion. I had the same problems with some of my plugins: need to tell the user in what order to load the dependency plugins. Hakim, your idea could solve that indeed! Order of plugins is then no longer important.

[Martinomagnifico]

Thinking of it, a dependency might not always be a dependency. For example, the MarkDown plugin would only be a dependency for your Menu plugin, if MarkDown is actually used somewhere in the deck, and only then if the user also wants a slidename inside that MD to be displayed in the menu. When the author writes in HTML, the dependency would not be there.

[rajgoel]

In my opinion, the plugins should not need to know much about each other. This is important as it would help the interplay of plugins from different developers. For synchronous plugins the current approach is perfectly fine in my opinion:

Plugins are currently loaded and initialized serially in the order they appear in the plugins array.

However, if plugins are asynchronous, there are potential problems:

Use case 1
Assume I want to create an asynchronous plugin that dynamcally loads content from external files. The menu-plugin doesn't know that this plugin exists and cannot wait for it. It only knows that it may have to wait for the markdown-plugin to load and parse external markdown files. This is hard coded in the plugin. Thus, currently the menu-plugin will not list the slides that are loaded dynamically. If, however, the menu-plugin would be initialized after the dynamic content is loaded, all slides would be listed in the menu.

Use case 2
Assume I use markdown from external files and I have a plugin loadcontent that loads external content from files and another plugin animate that animates svg graphics. The user now wants to use external markdown files for the presentation. Within these files there are elements with user-specified tags that tell the loadcontent plugin to load external svg. Now, the loadcontent plugin requires the markdown plugin to have loaded and parsed the external markdown in order to load the external svg, and the animate plugin requires the loadcontent plugin to have loaded the svg files. The serialized initiation is not sufficient in this case.

Use case 3
Like use case 2, but all the content is directly provided by the user in the html file. Thus, the animate plugin has no dependencies and can directly initialize the svg animations.

Concludingly, the dependencies may depend on the use case. Therefore, it should be the responsibility of the user to ensure that plugin dependencies of the use case are met and the plugin creator should only care about the core functionality of the plugin. The possibility to chain promises of plugins and adding plugins after other asynchronous plugins have completed could be a solution. If registerPlugin could return a promise after completion, this could do the job (sorry if I use the wrong wording here, just learning about promises ...).