hello, after some discussion in #clojurescript I think its worth to bring the discussion here, its about how to use JS libraries that depend on the JS native class system, currently there seems to be no way to extend on of those such classes and call its parent constructor (which is accessible via super in JS). This looks like a gap because makes very dificult to use those libraries with CLJS, is there some way to do it that I'm missing? or is there any plans on how we are going to handle this in the future? You can follow the original discussion from: https://clojurians.slack.com/archives/C03S1L9DN/p1557803014008100

@wilkerlucio far as I know ES6 classes can be decomposed into ES5 patterns

that said I've been thinking more about a defclass macro

but anyways, you should be able to inherit and call the parent prototype

there's tons of resources on the web about what ES6 classes look like in ES5 patterns

@dnolen I hit a limitation wall I think, seems like there is no way to unwrap the super call when the class is defined with native class system, @lilactown also pointed an article talking about this https://clojurians.slack.com/archives/C03S1L9DN/p1557805806015700

this is the gist of the problem:

https://esdiscuss.org/topic/extending-an-es6-class-using-es5-syntax

@wilkerlucio I would read through this first and tell me what you think

nice, that seems like an exit 🙂

I would like to see a lot more information before thinking about this more

if you feel like something is missing then write a JIRA w/ your research

and I will look over it carefully

thanks for pointing the resource, I'll try following the tips there and see if I can get it to work

if you feel like the solution is suboptimal will still consider an enhancement

@dnolen I did some tries, but no suggested solution can fix the problem of calling a native class constructor, the only way I found to get around is falling back to writing the classes in JS and loading that back again in cljs, I did open the issue: https://dev.clojure.org/jira/browse/CLJS-3084

@wilkerlucio one thing we will have to consider is exactly how deep the support will be

FWIW I'm unlikely to spend anytime on this in the near future

there's too much to consider

so somebody needs to draw up a plan - and then we can assess that

also it's worth thinking about comparing to just writing this kind of stuff in JavaScript

whatever we would do in ClojureScript would effectively be a messy JavaScript thing

yeah, that deserves some though, some way to make calling of super idiomatic, I can try start working out some syntax propositions and post in the ticket

I want to be clear that I'm not really interested in solving your specific problem

if we're going to do anything it should be a general solution

if the general solution is too wide a scope - then we're not going to do it

sure, I understand, I'm just trying to think around this because that's the blocker, but I understand its about generic class generation

k

then feel free to propose something!

particularly interested in something idiomatic - perhaps with eye for what Clojure has already done etc.