processing
[2.0] Document workarounds for inter-addon dependencies
Topic
There are some scenarios right now where you might want to have multiple addons in the same sketch. Sometimes, if those addons depend on each other, then the ordering of your addon script tags can affect whether or not the sketch runs correctly.
I proposed a potential API change in https://github.com/processing/p5.js/issues/7797 to help resolve these issues, but in the mean time, there are some workarounds that we can document.
- For end users: You can rearrange your script tags to put them in the correct order. There are slightly more involved instructions for doing this in OpenProcessing since you'd have to switch your sketch to HTML mode.
- For addon developers: @quinton-ashley had a good idea, and that is, bundling all of an addon's dependencies into one file. e.g. if your addon depends on the preload addon existing and running after your addon, then it could make sense to just include the preload code after your code in your bundled js file.
This documentation could live in https://github.com/processing/p5.js/blob/dev-2.0/contributor_docs/creating_libraries.md but also that document needs to be updated for 2.0 as well.
This issue is actively looking for a contributor! If you're interested but not familiar with the add-on library system in 2.0, you can also check out this article
cc @perminder-17
@VANSH3104 please do! This is specific to dev-2.0 branch only. Feel free to ping with any questions
@ksen0 i added this is this correct or need to change it or make a pr for this
Handling Addon Dependencies
When creating addons that depend on other addons or are used alongside them, you need to consider execution order and dependency management. Here are solutions for both addon developers and users:
For Addon Developers
Solution 1: Bundle Dependencies
For small, critical dependencies, include them directly in your addon:
// p5.combinedAddon.js
const combinedAddon = function(p5, fn, lifecycles) {
// Bundled dependency code
fn._preloadHelper = function() {
// ...dependency logic...
};
// Main addon code
fn.myFeature = function() {
this._preloadHelper();
// ...main feature logic...
};
};
p5.registerAddon(combinedAddon);
Solution 2: Runtime Checks
For larger dependencies, verify their presence
const myAddon = function(p5, fn, lifecycles) {
fn.initMyAddon = function() {
if (typeof this.requiredFeature !== 'function') {
console.error('Error: Please load required-addon.js before my-addon.js');
return null;
}
// Safe to proceed
return this.requiredFeature();
};
};
p5.registerAddon(myAddon);
For End Users
Loading Order Solution
Always load dependency addons first:
<head>
<script src="p5.js"></script>
<script src="dependency-addon.js"></script> <!-- Load first -->
<script src="main-addon.js"></script> <!-- Then dependent addon -->
</head>
In Web Editors (OpenProcessing, p5 Web Editor):
- Switch to "HTML mode"
- Manually reorder script tags
- Ensure dependencies load before addons that need them
I am in the middle of updating https://github.com/processing/p5.js/blob/dev-2.0/contributor_docs/creating_libraries.md for 2.0 and has not finished yet, shall I open a WIP PR for the progress instead?
@VANSH3104 It seems the example you shared above are still using the old addon syntax instead of the 2.x one?
@VANSH3104 I think the proposed bundling solution code is likely not the practical way addon authors would want to do this as it involve manually copying the code from a different addon. This might be more practical to achieve with a build tool based solution but that involves its own set of complexity as well. It is also redistributing a third party addon which can have its own problems separate from the technical considerations. @davepagurek Do you have some idea around here? I think the runtime check is a relatively good solution so far and the error message logging can also led nicely to consideration around exposing FES API to addon authors which we were thinking of before already.
I'm almost done with the edits to the creating libraries contributor docs and will open a PR later today or more likely tomorrow. We can also work out details on this there.
@limzykenneth Understood! I’ll be waiting for your PR. Please let me know if there’s anything else you need from my side.
I think the proposed bundling solution code is likely not the practical way addon authors would want to do this as it involve manually copying the code from a different addon.
@limzykenneth Yeah I concur.
If let's say p5play and ml5 both implemented this workaround hack of including the preload.js compatibility addon, and users wanted to use both libraries, ml5's inclusion of preload support after p5play's would override p5play's edited version that initializes instance props to the global scope and p5play would fail to load.
So I agree with Limzy that my workaround shouldn't be documented or encouraged. Effort would be better spent developing a more robust solution.
