Document/unit test ability for clients to initialize global mode explicitly

The TL;DR here is that it'd be nice to be able to initialize p5 global mode explicitly at any point in a web page's lifetime.

Currently there is no documented way to do this, but there is an undocumented way to do it: simply call new p5(), without any arguments.

So this issue isn't actually about adding any new functionality--it's just about documenting and/or adding unit tests so that tools or sketches that depend on it don't break in the future.

Use case for the p5 widget

In the p5 widget, we're currently trying to support scenarios where widget embedders may want to specify p5 addon libraries to load.

Currently, the p5 widget's preview frame works like this:

1. Dynamically add a <script> element to the page containing the user's sketch code (which expects to be run in global mode).
2. Dynamically add a <script> element with its src attribute pointing at a version of p5.

As soon as p5.js loads, it sees the setup/draw functions defined by the user's sketch and initializes global mode.

However, because the p5 widget loads p5 asynchronously, adding support for p5 addon libraries poses a conundrum:

• We can't load p5 addon libraries before loading p5 because they depend on e.g. p5.prototype.registerPreloadMethod() to function properly.
• It's difficult to load p5 addon libraries after loading p5 because p5 will have noticed that setup/draw exists in the global namespace and will start the sketch immediately, before we have a chance to asynchronously load any addon libraries.

While there are some ways the p5 widget could change its architecture to work around this, the easiest solution would be the following:

1. Asynchronously load p5.js, followed by any add-on libraries.
2. Add a <script> element to the page containing the user's p5 global mode sketch.
3. Activate global mode to start the sketch.

Step 3 is where we need ongoing support from p5. While it's possible right now, it'd be nice to have the functionality documented and/or unit tested, so that the widget doesn't break when used with newer versions of p5.

I've written a working proof-of-concept of this approach at https://github.com/toolness/p5.js-widget/pull/63.

Other benefits

Aside from making the p5 widget's implementation easier, I can think of a few other benefits to being able to explicitly start p5 global mode:

• It actually allows p5 global mode to be instantiated before page load, which means that folks who really want to work around the assigning variables using p5 functions and variables before setup limitation can write the following sorts of sketches:

  new p5();
  
  var boop = random(100);
  
  function setup() {
      createCanvas(100, 100);
  }
  
  function draw() {
      background(255, 0, boop);
  }
  

  Kind of weird, but it's nice to have it available as an option.

• One might argue that the ability to control the activation of p5 global mode isn't a feature "advanced" JS developers would need, because such users should just use instance mode. However, the value of the p5 global mode's API to advanced developers shouldn't be underestimated. There's lots of reasons they might still prefer to use global mode:

  • It's very expressive, while having to prefix one's sketches with the sketch instance suddenly makes one's code very verbose and harder to read.
  • It's still possible to use lots of third-party libraries without namespace collisions if one uses a module loader like requireJS or browserify.
  • One might start writing their sketch in global mode because it's easier, and needing to convert one's code over to instance mode just to have a bit more control over the way their sketch is loaded feels like an unnecessary trade-off.

• Advanced users and tools (like p5 widget, IDEs) can potentially improve page load times by asynchronously loading multiple p5 add-ons simultaneously. I don't think this is possible without those users/tools having the ability to explicitly control when p5 global mode is initialized, but I could be wrong.

No file or test path is specified. Start by locating the code and tests covering p5 global-mode initialization, then check how the documented API describes explicitly calling the constructor. Done means the supported behavior is documented and, if appropriate, covered by a unit test so it remains stable for asynchronous loaders such as the p5 widget.