Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
66 lines (47 sloc) 3.22 KB

May 19 (discuss)

Attendees

createClass() vs ES2015 Classes

Why Use Classes?

  • createClass() API feels outdated, and can be implemented entirely in userland if needed.
  • ES6 classes are less of an API, possibly simpler.
  • ES6 classes are friendlier to static analysis.
  • ES6 classes offer performance improvements in large apps.
  • We are in the business of UI components, not type systems.

What’s Holding Us Back?

Autobinding
  • Class properties solve this.
  • However they’re not moving forward at TC39 yet as Jeff is busy preparing for React Europe.
  • Downside: nobody wants experimental syntax in the documentation.
  • We could just always bind in constructor in the documentation.
Mixins
  • A lot of components on Facebook website still use mixins, but mostly the same ones.
  • If we decided to deprecate createClass in the future, we would need to fix them first.
  • Possible temporary workaround: apply them on top of ES6 class like react-mixin does.

#### Next Steps

  • We should update the documentation to use ES6 classes and functional components wherever possible.
  • Eventually we should deprecate createClass, possibly move it into a separate package.
  • We need to have a good solution for folks who don’t want to use a transpiler.

Separating Out PropTypes

  • Jordan and some Airbnb folks asked about separating PropTypes into a generic validation library.
  • One concern might be that as a separate project PropTypes could become incompatible (as a type system) with Flow or TypeScript.
  • Internally long term we’d like to avoid PropTypes usage and rely on static typing instead.
  • Some checks can’t easily be expressed statically (e.g. ranges or colors).
  • Conclusion: anyone can take PropTypes code and put it on npm.
  • If it enforces a generic enough contract, we might try to replace PropTypes with it in the future, but no guarantees.
  • Our internal plan will be to focus on ES6 classes and Flow.

New Release Proposal

  • React Native is releasing RC, so we’re shipping 15.1.0.
  • Originally we planned to ship 15.0.3 and 15.1.0, but we don’t plan to maintain two branches anyway, so not worth doing now.
  • We will release React versions every two weeks, a couple of days before React Native RCs.
  • We might start using Lerna, it works great for Babel.
  • Do we ship from a branch or from master? No conclusion yet.

Please feel free to discuss these notes in the corresponding pull request.