|
| 1 | +## June 9 ([discuss](https://github.com/reactjs/core-notes/pull/19)) |
| 2 | + |
| 3 | +### Attendees |
| 4 | + |
| 5 | +* [Alex](https://twitter.com/alex_frantic) (React Native) |
| 6 | +* [Dan](https://twitter.com/dan_abramov) (React) |
| 7 | +* [Jim](http://github.com/jimfb) (React) |
| 8 | +* [Keyan](https://twitter.com/keyanzhang) (React, intern) |
| 9 | +* [Sebastian](https://twitter.com/sebmarkbage) (React) |
| 10 | +* [Tom](https://twitter.com/tomocchino) (React) |
| 11 | + |
| 12 | +### Individual Updates |
| 13 | + |
| 14 | +#### Sebastian |
| 15 | + |
| 16 | +##### New Reconciler Plan |
| 17 | + |
| 18 | +* Making progress on the incremental reconciler ([PRs](https://github.com/facebook/react/pulls?utf8=%E2%9C%93&q=+fiber+is%3Apr+is%3Aclosed+author%3Asebmarkbage+)). |
| 19 | +* The next step is to support forking for pausing and cancelling reconciliation. |
| 20 | +* After that, the new reconciler needs to implement flushing changes (e.g. to the DOM). |
| 21 | +* This would take the bulk of the month, and then will be working towards reaching feature parity with existing reconciler. |
| 22 | + |
| 23 | +##### Observations about `setState()` |
| 24 | + |
| 25 | +* We currently [support](https://facebook.github.io/react/docs/component-api.html#setstate) `setState(callback: (state, props) => nextState)`. |
| 26 | +* It is not entirely clear how well that would work with incremental reconciler. |
| 27 | +* The issue is that props become very much “spread in time”: last render could be a while ago, and next render might be in the future. |
| 28 | +* Hard to say if this will turn out to be a problem, worth doing more investigation. |
| 29 | + |
| 30 | +#### Jim |
| 31 | + |
| 32 | +* Fixed a few issues in React DOM. ([#6986](https://github.com/facebook/react/pull/6986), [#7002](https://github.com/facebook/react/pull/7002), [#7003](https://github.com/facebook/react/pull/7003)) |
| 33 | +* Proposed a PR that warns if people mutate `props.children`. ([#7001](https://github.com/facebook/react/pull/7001)) |
| 34 | +* We will probably take this PR, Sebastian will be taking another look at it. |
| 35 | + |
| 36 | +#### Dan |
| 37 | + |
| 38 | +* Working on internal Facebook code to get rid of some of the most common mixins. |
| 39 | + |
| 40 | +#### Ben |
| 41 | + |
| 42 | +* Ben is enabling class property transform in the internal Facebook build pipeline. |
| 43 | + |
| 44 | +### Keyan |
| 45 | + |
| 46 | +* Error code work is finished! ([#6882](https://github.com/facebook/react/pull/6882), [#6946](https://github.com/facebook/react/pull/6946), [#6948](https://github.com/facebook/react/pull/6948)) |
| 47 | +* Will start working on a new codemod to convert more components to classes with property initializers. |
| 48 | + |
| 49 | +## Discussions |
| 50 | + |
| 51 | +### Warning for Mutating Children ([#7001](https://github.com/facebook/react/pull/7001)) |
| 52 | + |
| 53 | +* In general, this seems like a good idea, but people are using children in a ton of crazy ways in the wild. |
| 54 | +* We have to figure out if the introduction of this warning is a breaking change or not. |
| 55 | +* We will enable it on Facebook website to see how many callsites are affected. |
| 56 | + |
| 57 | +### Current Progress on ES6 Classes |
| 58 | + |
| 59 | +* Ben is working on enabling property initializers in Facebook codebase. |
| 60 | +* Keyan is working on a new `createClass` → ES class component transform that uses property initializers (rather than binding in the constructor). |
| 61 | +* Dan is working on getting rid of some of the internal mixins on Facebook websites. |
| 62 | +* Still need to figure out what to do with `PureRenderMixin`. |
| 63 | +* Property initializers are currently extremely verbose with Flow, and this needs to be fixed. |
| 64 | + |
| 65 | +### Proposals Champion Process |
| 66 | + |
| 67 | +* We might want to adopt a proposal champion process similar to TC39. |
| 68 | +* Everyone has an idea of what they want to add / change / fix, but once you start digging into it, there’s just so much context needed, and it’s so hard to change. |
| 69 | +* We’d like to have internal champions the same way TC39 has champions. |
| 70 | +* The responsibility of that person is to answer any question that arises. |
| 71 | +* At TC39, you are expected to have all the answers to the questions, or the thing you’re pushing through gets delayed. |
| 72 | +* Secondary champions can step up to champion other peoples’ ideas (e.g. helping to move a community proposal forward). |
| 73 | + |
| 74 | +------------ |
| 75 | + |
| 76 | +Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/19). |
0 commit comments