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

Add May 19 notes #15

Merged
merged 1 commit into from
May 21, 2016
Merged

Add May 19 notes #15

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions 2016-05/may-19.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
## May 19 ([discuss](https://github.com/reactjs/core-notes/pull/15))

### Attendees

* [Ben](https://twitter.com/soprano) (React)
* [Christopher](https://twitter.com/vjeux) (React Native)
* [Dan](https://twitter.com/dan_abramov) (React)
* [Jim](http://github.com/jimfb) (React)
* [Keyan](https://twitter.com/keyanzhang) (React, intern)
* [Paul](https://twitter.com/zpao) (React)
* [Sebastian](https://twitter.com/sebmarkbage) (React)
* [Tom](https://twitter.com/tomocchino) (React)

### `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](https://github.com/jeffmo/es-class-fields-and-static-properties) solve this.
* However they’re not moving forward at TC39 yet as [Jeff](https://github.com/jeffmo) 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](https://github.com/brigand/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](https://twitter.com/ljharb) and some Airbnb folks asked about separating `PropTypes` into a generic validation library.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this idea. For folks who cannot (for various reasons) add Flow to their projects, being able to reuse the validations from PropTypes declarations would be immensely helpful to increase type validation coverage to their non-React code.

* One concern might be that as a separate project `PropTypes` could become incompatible (as a type system) with Flow or TypeScript.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is PropTypes validation removed when compiling with NODE_ENV set to production?
If not, then while visiting this topic it would be an interesting constraint to add.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that for performance reasons propTypes is only checked in development mode.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that but by looking at the code , it seems that the minifierr must be able to ignore unused require calls. Can it do that?

Copy link

@timche timche May 21, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to do that on your own.

Note: by default, React will be in development mode. To use React in production mode, set the environment variable NODE_ENV to production (using envify or webpack's DefinePlugin). A minifier that performs dead-code elimination such as UglifyJS is recommended to completely remove the extra code present in development mode.

If you are looking for removing propTypes in your components, then use this: babel-plugin-transform-react-remove-prop-types

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there may be separate types of optimizations being confused.

  1. React does not call propType validators in production. To enable production mode, you either need to envify it with NODE_ENV set to "production" or use precompiled react.min.js.
  2. Nevertheless React bundles code necessary to validate propTypes. This shouldn’t affect you, but Dead code eliminate React.PropTypes checkers in production facebook/react#6401 solves it if it gets merged.
  3. Your components would still define propTypes in production, React just won’t read them. If you want to save some bytes by stripping out those annotations from your code, you can use babel-plugin-transform-react-remove-prop-types.

I hope this helps!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gaearon Thanks, that PR was exactly what I wanted. I already do 1) and 3), 2) affects me as it's more bytes in the wire. ;)

However, seeing a PR already in line for 16.0 means it has been taken care of.
Although shouldn't ReactElementValidator require in the React.js file be moved to the DEV block?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, quite possibly! Feel free to send a PR.

* 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](https://github.com/facebook/react/blob/619b3e850998ad24b9750c83ca20bb95e7638957/CHANGELOG.md#1510-may-20-2016).
* 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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about this. My company hasn't migrated to React 15 yet so seeing that we might have to invest more time in updating libraries is worrying.

Is there any document highlighting pros and cons of moving to faster/slower release cycle? What could be the impact on the ecosystem? Are there any statistics of how fast new React versions are adopted?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn’t mean we plan to ship v16 soon. We usually wait at least three months before releasing a new major version, and this isn’t changing.

It means that now we’re on 15.x major, we can ship new features and bug fixes faster. So you’d expect 15.1.0, 15.0.1, 15.0.2, 15.2.0, etc, being released more regularly, and you can adopt them right away. There is no need to “invest more time in updating libraries” because these versions are still 15.x, and you can adopt them at any moment without making changes to your code.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating libraries, even without code changes is not free. You need to check that the changes are not introducing regressions (because of a bug in React or a bug in the interaction between application code and React). I'm not saying switching to two weeks release is bad, just that I don't think it is a change to take lightly, because of the potential effects on the community.

* We might start using [Lerna](https://lernajs.io), it works great for Babel.
* Do we ship from a branch or from master? No conlusion yet.

------------

Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/15).