[p5.js 2.0] Unnecessary arguments supplied to addon function by p5.registerAddon

[quinton-ashley]

Topic

I'd like to suggest a change to p5.registerAddon before the release of p5.js 2.0.

Currently it passes: (p5, fn, lifecycles)

But it's only necessary to pass lifecycles to addon functions.

Users already need access to p5 to call p5.registerAddon, so it's confusing to provide them something they already have, even when using the same name for it.

The fn name could make sense to people familiar with jQuery's addon system but that's a stretch. Otherwise "fn" is already common shorthand for "function" and addon devs may want to use that variable name for other purposes such as iterating through functions. It's best to leave the naming of a shortcut for p5.prototype up to addon devs because it's not helpful to give it a generic name that obfuscates what it is imo.

Ideally addon registration examples could look simpler with shorter function signatures like this:

p5.registerAddon((lifecycles) => { 

  const proto = p5.prototype; // user defined shortcut, if desired

  // ...addon code

});

[limzykenneth]

The addon is

function addon(p5, fn, lifecycles){
}

not

p5.registerAddon(function(p5, fn, lifecycles){
});

The existance of p5 when the addon is defined is not guaranteed. Yes it would be the case in script tag usage where addons are encouraged to have the second version above, but the addon can also export the addon function (first one above) to be imported by a sketch using ESM:

// addon.js
export function(p5, fn, lifecycles){
  // Define addon code here
}

// ESM p5 sketch
import p5 from "p5";
import addon from "./addon.js";

p5.registerAddon(addon);

const sketch = function(p){ /* ... */ };

new p5(sketch);

[quinton-ashley]

@limzykenneth Ah okay, that makes sense. It still would've been nice to make lifecyles the first param though, as it's not always necessary to provide p5.