P5.js: ES6 style class extension of p5 instance mode sketch.

[alimansfield2016]

It has been previously suggested that the P5.js library may at some point allow instance mode sketches using ES6 style class extensions. Currently, it seems however, that the library does not entirely work using this method as is.
One of the issues that i found, is that the sync argument, (that i believe is supposed to define whether the start of the sketch is sync or async?) is unused. Because the sketch always starts sync, if there are any variables in the sub-class that are passed as constructor arguments, they are not yet initialised as this. properties when setup is called, since is is called from within the super call.
Another issue that I came across was that when draw and other async methods are called, they do not seem to be correctly bound to the p5 ojbect, causing issues that prevent drawing etc.
As for the second issue, I was able to rectify it generally by binding all of the async function calls to this.

let _socket = io();
class sketch extends p5 {
super
    constructor(socket){
        //super must be called before any this assignments. even so, async should be an option?
        super(()=>{}, document.getElementById("sketch"), true/*doesn;t do anything*/);
        this.socket=socket;
    }
    setup(){
        this.socket.on("messgage", doSomething);
        //error this.socket is not defined;
        //if this was async, super returns, socket assigned, then setup called async.
    }
    doSomething(){}
}
new sketch(_socket);

Anyways, i know this is a bit long, but I think that it would be much nicer to be able to instantiate p5 as an extended class rather than having to use a seed function to spawn a sketch,

---

edit: forgot some this.s

[welcome[bot]]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, be sure to follow the issue template if you haven't already.

[micuat]

not supported at the moment... https://github.com/processing/p5.js/issues/4215#issuecomment-610423335

should we close this or is there any plan to support this? @limzykenneth

[limzykenneth]

It is currently not supported and any such use is up to the user's discretion. That said, I think it is a nice to have but I'm not sure if the library can support it at all and if there's interest from contributors to put in the time and effort to implement support.

[lmccart]

We've been working to adopt a position of "only adding new features that increase access/accessibility". So if there's not a clear argument here about how this expands access, and given that it's quite a complex add, I'd recommend we close this for now.