[2.0] Document workarounds for inter-addon dependencies #7798
Comments
|
This issue is actively looking for a contributor! |
|
@ksen0 can i give it a try? |
|
@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 DependenciesWhen 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 DevelopersSolution 1: Bundle Dependencies // 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 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 UsersLoading Order Solution <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):
|
|
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? |
|
@limzykenneth can you check it now ? |
|
@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. |
@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. |
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 #7797 to help resolve these issues, but in the mean time, there are some workarounds that we can document.
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.
The text was updated successfully, but these errors were encountered: