Stumped on binding to Javascript superclasses

#1

I’m attempting to write a binding for BaseButton here:

https://kmagiera.github.io/react-native-gesture-handler/docs/component-buttons.html

The API as written expects users to extend it using

class XButton extends BaseButton { ... }

I’m struggling to understand how a binding to BaseButton should look so that it’s possible to build new Buttons in Reason.

Anyone have any pointers, thoughts, or examples?

#2

I found this answer from back in 2017.

Is this still the best way to go?

#3

I hope using [%%bs.raw] is not the recommendation still! Great question, because there is a lot of ES6 Classes code getting created all the time.

I am wondering if your dev environment has Babel? If so, then class XButton extends BaseButton is going to get transpiled down to something like just a chain of function calls. This would be a lot more suitable for binding your ReasonML code onto.

var XButton =
/*#__PURE__*/
function (_Basebutton) {
  _inherits(XButton, _Basebutton);

  function XButton() {
    _classCallCheck(this, XButton);

    return _possibleConstructorReturn(this, _getPrototypeOf(XButton).apply(this, arguments));
  }

  return XButton;
}(Basebutton);

;
#4

Oh, that’s certainly an interesting way to go about it.

Currently, I’m working on a React Native app so I guess it’s Metro bundler which uses babel under the hood.

I do wonder whether or not there’s anything to watch out for if I choose to go down the path of binding onto the transpiled resulting code?

#5

Here’s the previous discussion on this Extending a JavaScript class

#6

Thanks for linking. let’s move the conversation over there.

Even though supporting class inheritance is crappy, there is a lot to be gained from providing a standardized route by which to bind to javascript APIs that expect developers to extend classes.

Writing bindings on a class based inheritance API shouldn’t be this painful – and I’m sure could end up being one of the reasons state within teams/companies for why it’s not worth using ReasonML over Typescript or similar.

#7

The OO part of Bucklescript wasn’t focused on. The output is large and ugly, OCaml does have object inheritance so probably this is only a matter of priority. Bucklescript is a 2 man team not every features of Javascript will be added