Skip to content
This repository has been archived by the owner on Jul 19, 2019. It is now read-only.

Latest commit

 

History

History
65 lines (47 loc) · 3.22 KB

may-19.md

File metadata and controls

65 lines (47 loc) · 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.