Methods on component accessible to JS

Hi,

We have created a facade for ag-grid-react using ScalablyTyped. The basic functionality is working fine, but the grid allows for things like custom cell renderers and cell editors to be specified as react components. I am able to pass in components using either a function as described in INTEROP.md, and with component.cmapCtorProps[…](…).toJsComponent.raw.

However, the grid requires some extra “lifecycle” functions to be available on some of the components, such as getValue(): js.Any, which the grid uses to get the new value after editing is completed. I was hoping that if I put the functions in the Backend of the component, they would be visible to the grid. But, no matter what I try, I get this helpful message in the console: “ag-Grid: Framework component is missing the method getValue()".

Is there a way to make extra functions in a component visible to the grid?

A jsx example of what I’m talking about is: https://github.com/ag-grid/ag-grid-react-example/blob/master/src-examples/richGridDeclarativeExample/NameCellEditor.jsx In the jsx, they just define the lifecycle methods right alongside the render method.

Thanks!

[toddburnside]

Thanks for the response @japgolly . At the moment we are looking into an option that does not require the above. If that doesn’t work out, I may try the JS wrapper for the Scala component.

[japgolly]

I believe I’ve come up with a solution to this.

• For starters, users must annotate members in their backend with @JSExport. Eg:

  class Backend($: BackendScope[Unit, State]) {
  
    @JSExport
    def welcome1() = "why hello there!"
  
    @JSExport
    def welcome2 = "hey mate!"
  
    @JSExport
    var v = 123
  
    @JSExport
    val field = "i'm a field"
  

• We could make scalajs-react add code to component constructors (either for all components with backends, or maybe if a directive is specified in Scala) so that when a component and backend is first created, the JS uses runtime reflection to automatically generate forwarders on itself to the exposed methods in the backend.

  Say m is a raw instance of a Scala component with a backend, m.backend gives you the backend class and Object.getOwnPropertyNames(m.backend.__proto__) returns a superset of all exposed methods. We can then iterate over them, filter out conflicts, and generate forwarders. Each forwarder would depend on the member type (fn, fn(), var, val, anything else?).

  

• Extra points: maybe these should be added to m.__proto__ once rather than every instance of m? It’s probably more efficient and might be more idiomatic for the JS world (?). Will have to investigate the nuances and details of how JS and prototypes work.