Open limzykenneth opened 1 month ago
@limzykenneth I like the idea but it's a bit unclear from your example code how this would achieve the goals of esm support for example. Could you elaborate on that and show an example?
Also I don't understand the purpose of using an anonymous function, the first and last lines in your example.
p5.js users might be loading multiple libraries and the current implementation of p5.prototype.registerMethod
already supports multiple libraries hooking into init, preload, setup, pre and post draw quite well with more standard and familiar JavaScript event style syntax. How could lifecycles
support this? Also the syntax seems more similar to deprecated onclick
functions, the old way of handling events in js.
I'm also confused how library creators could access a p5 instance.
Increasing access
Addon libraries have always been an important part of the p5.js ecosystem, expanding its capabilities with community contributed features that solve problems that p5.js itself may not necessarily address. Providing a flexible and easy to use interface to author addon libraries will further this effort.
Which types of changes would be made?
Most appropriate sub-area of p5.js?
What's the problem?
Currently to author an addon library to work with p5.js, the library author will often need to attach methods directly to
p5.prototype
which by itself is not a bad idea but addon libraries often need to do more than that.While async/await setup() proposed in #6767 provides a potentially new way of handling async functions, current libraries that need to hook into
preload()
require the use of internal functions.The lifecycle hooks feature of the current addon library API is also not entire consistent with room for improvement. Finally with a new syntax, there is room for even more customizability, combined with #7014, one can even add or overwrite renderers available to p5.js.
What's the solution?
Existing libraries should have a level of compatibility or require minimal updates to work with p5.js 2.0. This means if existing libraries rely on attaching methods to
p5.prototype
it will likely still work.A new method of authoring libraries will be introduced that is more ergonomic. This will be through a factory function that exposes reasonable interfaces for completing the following tasks as necessary:
As reference, Day.js provide plugin interface in the following way:
And is used with:
While jQuery provides the following interface:
fn
above is just an alias toprototype
which in essense makes jQuery's plugin system identical to what p5.js does.p5.js plugins have some properties that are not present in the Day.js or jQuery use case. With Day.js, plugins are expected to be explicitly provided through
dayjs.extend()
while p5.js addons should have the expectations of being available immediately upon inclusion/load. jQuery plugin don't need to content with lifecycle hooks or other non-class instance related features. A p5.js addon should also have the flexibility of being imported as a ES module or included through a script tag, ie. there should be a ES module version and a UMD version ideally.The proposed interface that a p5.js 2.0 plugin can have is as the following:
Pros (updated based on community comments)
Cons (updated based on community comments)
Proposal status
Under review