Consider specifying functions as member functions instead of class fields

[mwaibel-go]

Consider the use case of extending a Mark with a subclass. If I wanted to only add functionality to the render function, the idiomatic way in class-based JavaScript would be:

class MyRect extends Plot.Rect {
  override render(...args: Parameters<Plot.Rect['render']>): SVGElement | null {
    super.render(...args)
    // Additional functionality
  }
}

However, this isn’t possible because render is declared as a property on RenderableMark, so it doesn’t live on the prototype chain, but is instead copied to each instance, even subclasses’ instances (the way I understand it; I’m no TS or JS guru myself). Therefore it isn’t accessible via super.render. This forces us to use this (IMHO) rather unwieldy function definition:

override render = (...args: Parameters<Plot.Rect['render']>): SVGElement | null => {
  Plot.Rect.prototype.render.apply(this, args)
  // Additional functionality
}

I understand this is idiomatic to the hardened JavaScript veteran, but I would personally prefer the first definition.

[Fil]

related to #2422 #2425

[mwaibel-go]

Damn, you’re fast! Thank you!

The ‘subtypes’ of marks, for instance rectX and rectY, are currently only available as helper functions. Is there any chance we could get those as proper subclasses, too? Currently we have to extend Rect and copy over the handling of the default options from the rectX or rectY functions.

[Fil]

I don't think we want to bear the cost of supporting that for all relevant marks (as this would add 22 symbols in the API and add constraints).