Best practice to import a P5.js library

[boonier]

hey there, nice integration, thanks

just wondering what would the best way to go about importing a 3rd party library to use with this component, for e.g. https://antiboredom.github.io/p5.riso?

[tonyketcham]

Thanks, @boonier!

For an internal enhancement to this component, the library would ideally support an instance namespace instead of the global namespace -- for that, we could perhaps add an optional hook for registering those libraries.

It does appear that p5.riso supports p5's instance mode, so I'll play around with integrating that with p5-svelte and think more on that internal hook to generalize the solution to all compatible p5 libraries.

In the case of globally namespaced libraries, your mileage may vary and your IDE/the svelte compiler may error out thinking the library isn't defined if you try to register it globally in say, app.html or a <svelte:head> component

[tonyketcham]

Quick correction after exploring riso -- it still pollutes the global namespace as its vehicle into p5's instance mode. I'm testing if there's a way to avoid that causing the aforementioned errors that bubble up from attaching things to window in Svelte.

[boonier]

Thanks @tonyketcham I've tried the global import in both app.html and svelte:head with mix (yet unsuccessful) results.

Are suggesting a prop that accepts something like and array or object containing a reference to the library, that p5-svelte wraps internally to namespace it?

[tonyketcham]

I also tried every permutation of how I'd approach importing Riso and came up unsuccessful. Riso's method for latching onto an instance also hijacks every instance on the page which would be something I don't want to support in this library since that'll cause isolation issues in the case of multiple <P5/> components per page.

And yes, passing a set of references to third-party libraries on to p5-svelte under the hood to mount after the p5 instance is created was what I was thinking. However, that particular approach only works for libraries that support import syntax.

For Riso, it may be easier to fork the library and convert it to ESM syntax that can optionally accept a direct p5 instance to operate on, rather than defaulting to mounting on window.

[boonier]

For Riso, it may be easier to fork the library and convert it to ESM syntax that can optionally accept a direct p5 instance to operate on, rather than defaulting to mounting on window.

...along the lines of what I was starting to think. I'll look into it and let you know.

cheers for digging into this though :)