Coverage remained the same at 100.0% when pulling 9cb51ed on createref-support into fe76b79 on master.

Had to read up on the backstory a bit on why react made an the API change. It's basically because of code like this:

class Foo extends Component {
  frames = [];

  render() {
    // <div> is passed a new function on each render()
    return <div ref={el => {this.frames.push(el)}} />
  }
}

Overall, it's great to see more work being put into removing wrong usages of an API, but I must admit that I'm a bit worried that this will be the first change of many others where we "memoize" function creation.

Spoke a bit with Dan at JSConf about this and the render props pattern which has a similar issue. The React team is currently exploring alternative ideas and would like to make them unnecessary at some point in the future. There are no short term plans for that, though. It just something they are currently exploring.

I wouldn't worry too much about supporting react-create-ref. It's only a temporary polyfill to ease migration to react v16.3+. Once migrated, there is no use for react-create-ref anymore.

@developit Does your second implementation work as well as the changes in this PR? Just tried it out and it would be 5 bytes smaller.

@marvinhagemeister it works pretty similarly. I'm actually seeing a performance improvement with this implementation though, so I might try to benchmark between the two for comparison.

The alternative version is technically different from how React implements createRef (since it returns a function with a .current property), but the outward API is the same.

@developit Right, thanks for getting back to me. In that case I think we should not deviate too much from react.

ping @lukeed

Are we thinking the 38 byte hit is okay?

Sorry for the delay, crazy week.

The only shavings (lol) I can suggest is typeof ref == 'function' into !!ref.call.

Other than that, I think I'm of the mindset that we should become react-16 compatible all at once, when that point comes, rather than piecemeal some 16 attributes. Will be harder for users to keep track of what we currently do / don't do while still intentionally being incomplete.

I think I tried the ref.call bit but it ended up producing a larger output since we already do typeof checks in the codebase but don't currently have any .call.

Other than that, I think I'm of the mindset that we should become react-16 compatible all at once, when that point comes, rather than piecemeal some 16 attributes. Will be harder for users to keep track of what we currently do / don't do while still intentionally being incomplete.

I tend to disagree. Lack of support for react-16 features could be holding back adoption of Preact due to incompatibility with libraries (eg. reach/router#9). Rolling out support as soon as a feature is ready could help adoption. For example, I'm super keen to use Preact in production but am held back through issues like this.

Merging as everybody is happy with the change 🎉

Sorry in advance if this is a dumb question.
Is there a way to get createRef to work with preact.min.js? Like is there a version of that file floating around somewhere that has react.createRef() support?

@gordygordy No, we haven't made a new release yet. If absolutely need the latest unreleased code from master (note that it may be unstable), you can clone the repo and just run npm run build to create the same files as we ship on npm.

I think I solved it, i just pasted this into the bottom of the preact.min.js file and now everything works :)

function createRef() {return function ref(c) { ref.current = c; }}

@gordygordy I'd recommend avoiding modifying anything in node_modules if possible, it'll get reset when you install stuff.

Can the react-create-ref package be used with preact in the meantime, waiting for the next release?

@MathieuLoutre should work right out of the box with react aliased to preact

I've tried it and it seems to work brilliantly. Just wanted to make sure that it was supposed to do that ;) Thank you!