change load order preload method

[stalgiag]

trafficstars

This feature request is based on the discussion in #3347.

Essentially some users may want a p5 sketch to load first when used as an element on a page with a high number of external assets. @calebegg proposed that this could be achieved by initializing p5 with the DOMContentLoaded event rather than the load event which is the current default.

Here is a visual explanation of the difference between the two events..

What do people think about this as a feature?

[vedhant]

@stalgiag I feel we could use DOMContentLoaded if the sketch is independent of the entire webpage. It would make the sketch load much faster. However if the sketch requires, for example, an image to load then onload will have to be used. How do you suggest we incorporate both?

[limzykenneth]

I'm thinking it would either be explicit or implecit.

Explicit meaning that we choose as a default DOMContentLoaded but if a user wants some assets to have already loaded, they would need to specify in some way for the library to use onload instead.

Implicit would mean that we will need to somehow detect which case would be the best, such as if the user have code that references assets in the DOM then uses onload and vice versa.

[stalgiag]

Yes @limzykenneth I was suggesting something explicit but if anyone has any thoughts on how it might be done implicitly that would be really neat. I am not sure how that detection could be written.

[limzykenneth]

I have no idea either about how to implement the implicit one (not off the top of my head anyway) but I feel that the explicit route may be a bit much for a beginner to handle if the default is DOMContentLoaded.

[Spongman]

i would recommend retaining the current default and adding an explicit switch (maybe p5.useDOMContentLoaded = true' ?) for those that are aware of the caveats.

[ksen0]

To move forward, this issue needs an API design proposal, that (1) takes the existing discussion into account and (2) is consistent with existing API in 2.0. It may also be useful to consider the API criteria that @GregStanton has previously proposed:

Consistency: Provide a similar interface for similar features and different interfaces for different features. Readability: Design features that are easy to read and understand. Writability: Make features easy to use and hard to misuse. Predictability: Respect the principle of least surprise, so that users can guess how features work. Extensibility: Hide implementation details and lay a foundation for add-on libraries. Economy: Limit redundant features, and consider add-on libraries for new features.

If you're a new contributor (welcome!) interested in loading behavior, consider checking out this issue which is ready for work: https://github.com/processing/p5.js/issues/6795

PS: This message is part of cleaning up the p5.js 2.0 roadmap prior to release, to make outstanding more more approachable for new contributors. You can join the conversation about this new version on this Discourse thread or this GitHub thread!