Accept Ref Objects as Refs?

[sebmarkbage]

Reason React uses first class OCaml refs to store mutable values (instead of on this instances).

These are basically just an object with a mutable contents property. These can be updated with callback refs n => ref.contents = n but it would be a nice convenience feature to just have that built-in.

We could also make these first class objects on isomorphic React.

React.createRef = () => ({ contents: null });

class Foo extends React.Component {
  state = {
    myDiv: React.createRef()
  };
  componentDidMount() {
    if (myDiv.contents) {
      myDiv.contents.focus();
    }
  }
  render() {
    return <div ref={this.state.myDiv} />;
  }
}

Basically the implementation would just be:

if (typeof ref === 'function') {
  ref(newValue);
} else if (typeof ref === 'object') {
  ref.contents = newValue;
} else if (typeof ref === 'string') {
  owner.refs[ref] = newValue;
}

This is something that needs to be implemented in the core runtime and not as part of any particular component API since refs cross that boundary.

cc @adamjernst

[sebmarkbage]

The thing that is special about OCaml is that there is already a first-class language feature for these. So you would by-pass React.createRef() and just use { myRef: ref Node }. There is also syntax sugar for accessing this value. (!state.myRef).focus

[syranide]

Each ref object being allocated separately is not great, but refs are perhaps not prevalent enough for this to really be a concern, and in practice this would probably even end up being faster as most people use the inline fat-arrow syntax which is (currently) inefficient.

Could one imagine a form that would work for arrays of elements too? (i.e. when you want to keep a ref to each of the items in a list) Otherwise, that seems problematic for users to achieve in React if they prefer this style.

[syranide]

I'm guessing it wouldn't be unthinkable to have native support for refs either? It would just act exactly as the value it is referencing, except there's some way of updating the ref, e.g. setRef(myRef, newValue).

[sebmarkbage]

I suppose one issue is that this doesn't actually compile to{contents:...} with BuckleScript. It compiles to an opaque object like [...]. So we wouldn't know the data structure's signature anyway.

So maybe this does indeed have to use ref callbacks as the interop layer.

cc @chenglou

[chenglou]

The record compiles to an array of a single item. It's an internal representation (though unlikely to change). A bit torn...

[gaearon]

Out in 16.3