Load jsPsych plugins dynamically

[becky-gilbert]

Summary

Currently we're loading a static list of plugins in all jsPsych studies (regardless of whether or not the study code actually needs those plugins). It would be better to allow users to select the plugins they need from a checklist, and then load dynamically from that list for each experiment.

Description

There are currently ~50 "official" jsPsych plugins that researchers might want to use in their experiments, and our jsPsych study template loads 5 of these. We also always load all 5 plugins, regardless of whether or not the study needs them. Each plugin that is loaded results in an additional request to the jsPsych package CDN, which increases the study's initial load time (which we've already noticed is slow: lookit/lookit-jspsych#87), so automatically loading all plugins for every study is not a great solution.

Rather than loading the same set of plugins for all studies, we should provide a multiple-selection list on the jsPsych study edit form so that users can select all of the plugins that they need for their study. In the jsPsych study template, we could loop through the plugin list for that particular study and constructs the script elements accordingly. The CDN source URLs follow a predictable pattern of: https://unpkg.com/@jspsych/PLUGIN-NAME@VERSION, making it very easy to construct the URLs using only the plugin name and version.

This way, each study would only be loading the plugins they need, and users would have access to the full set of jsPsych plugins.

This would require the following changes:

• Update the jsPsych study edit form with a multiple-select checklist, populated with the full set of plugins and associated versions
• Add the plugin list to the study model/context and make it available to the jsPsych study template
• Add a for loop to the study template that loops through plugin list and adds the script elements
• Possibly store the integrity SHAs that are associated with each plugin so that these can be added to the script elements

Questions

How should we handle plugin versions?

• We could simplify things by leaving out the plugin version, which would mean always linking to the 'latest' version, but this means that a researcher's code could change unexpectedly whenever jsPsych puts out releases.
• Offer a static set of versions (e.g. current latest version for each plugin) and update these manually as new jsPsych releases come out.
• Add an associated 'version' option in the plugin form question where users can specify a valid version. This would be more complicated to set up, because the study table would need to store both the plugin name and version (rather than just name), plus we would either need to get rid of the integrity SHAs or store them for all versions. But it would mean that researchers could use different plugin versions and optionally update whenever a jsPsych release comes out.