├── 2016-03 └── march-31.md ├── 2016-04 ├── april-07.md ├── april-21.md └── april-28.md ├── 2016-05 ├── may-05.md ├── may-12.md ├── may-19.md └── may-26.md ├── 2016-06 ├── june-02.md ├── june-09.md ├── june-23.md └── june-30.md ├── 2016-07 ├── july-07.md ├── july-21.md └── july-28.md ├── 2016-08 ├── august-04.md └── august-25.md ├── 2016-10 ├── october-13.md ├── october-20.md └── october-27.md ├── 2016-11 ├── november-03.md └── november-10.md ├── 2016-12 ├── december-01.md └── december-08.md └── README.md /2016-03/march-31.md: -------------------------------------------------------------------------------- 1 | ## March 31 ([discuss](https://github.com/reactjs/core-notes/pull/1)) 2 | 3 | ### Fostering external collaboration 4 | 5 | #### What would a React roadmap look like? 6 | 7 | * Need to document “what we want” so we have something to point back to 8 | * Either a single document (roadmap?), or a set of issues with tags 9 | * Suggestion: create a separate repo for RFCs (like Ember) 10 | 11 | #### PRs should not get stale 12 | 13 | * We recently closed a bunch of old PRs 14 | * If we don’t want something, we should close it sooner and communicate why 15 | * Major source of confusion is that no one knows which release a particular PR or issue is a priority for 16 | * Having a roadmap would help this tremendously, but even if we don’t have one, just tagging PRs with milestones would help ensure timely responses, etc 17 | 18 | #### Linking to PRs from our release notes 19 | 20 | * Makes sense for high level things 21 | * For bugs and whatnot, this might be super noisy 22 | * Could boost morale for contributors 23 | * Right now it’s hard to compare the difference between different versions, this could help 24 | * We’ll try it for the v15 release notes and see how it feels 25 | 26 | ### Releasing 15 27 | 28 | * A few blockers related to `setAttribute`: 29 | * https://github.com/facebook/react/issues/6219 30 | * https://github.com/facebook/react/issues/6119 31 | * Paul is going to write up a final tracking issue 32 | * Final 15 should be released next week 33 | 34 | ### Separating Addons 35 | 36 | * We don’t use them much internally, and have been letting feature requests and issues get stale 37 | * How do we separate them? 38 | * If we move them to a different repo we will never look at it again 39 | * We don’t currently look at them, but we at least feel guilty about it 40 | * Should we be less afraid to disown code? 41 | * `update()` is simple because it’s tiny 42 | * `ReactTransitionGroup` is really complicated 43 | * Have to figure out the logistics here, but we’re going to move them into their own [reactjs](http://github.com/reactjs) repo 44 | * If there’s already something better, we should link to that instead 45 | 46 | ### Trying JavaScript Styles in Internal Facebook CSS Infrastructure 47 | 48 | * There are *tons* of different ways to render JS styles (see Radium, CSS Modules, React Native Web, etc) 49 | * One of the biggest things we need to figure out is performance 50 | * [Christopher](http://twitter.com/vjeux) is experimenting with converting internal CSS build pipeline at Facebook to output JS instead of CSS 51 | * The plan is to convert some of the Facebook products to use JS styles and profile different approaches 52 | * If there are good results we might eventually consider supporting something like this in React DOM 53 | * **This work is tied to the internal Facebook CSS build pipeline, is very experimental, and might not give any results** 54 | 55 | ------------ 56 | 57 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/1). 58 | -------------------------------------------------------------------------------- /2016-04/april-07.md: -------------------------------------------------------------------------------- 1 | ## April 7 ([discuss](https://github.com/reactjs/core-notes/pull/3)) 2 | 3 | ### Releasing React 15 4 | 5 | #### Shipping Today 6 | 7 | * React 15 is shipping! 🎉 8 | * Docs should be in good shape. 9 | * Just need to proofread the [blog post](https://github.com/facebook/react/pull/6396) and ship it. 10 | 11 | #### Relay Test Failure 12 | 13 | * We changed React to use `object-assign` npm [ponyfill](https://ponyfoo.com/articles/polyfills-or-ponyfills) that falls back to native `Object.assign`. ([#6376](https://github.com/facebook/react/pull/6376)) 14 | * This caused a Relay test to fail internally because native `Object.assign` did not preserve key ordering. 15 | * Test will be fixed to not rely on this. 16 | * This won’t block React 15 release. 17 | 18 | #### React Native Issue 19 | 20 | * `react-native init` installs `react@latest` which would break when we release React 15. 21 | * Sorted out with [James Ide](https://twitter.com/ji). 22 | * Since we communicate with [Exponent](https://twitter.com/exponentjs) frequently, we were able to fix this preemptively. 23 | * We’ll release 15 but keep 0.14 `latest` on npm for a while (hopefully a few hours) until React Native gets a fix. 24 | * It will take some time to update React Native to use React 15, just like before. 25 | 26 | #### Branch Planning 27 | 28 | * At a high level, things will be slightly different than they’ve been historically because we now have actual minor versions. 29 | * We’ll need to maintain both a patch release and a minor release going forward, so we need to figure out how many releases we’re going to support officially. 30 | * This was also a common question from the community (what is our official story around support of past releases?). 31 | * Node does labels on every request, we’ll need to figure out what our strategy will be so we cherry-pick all the changes correctly. 32 | * [Paul](https://twitter.com/zpao) will study how Node does it and come up with a plan. 33 | 34 | #### Rolling Changelog 35 | 36 | * Let’s maintain a continuously updated changelog so we don’t have to spend hours (sometimes days!) writing release blog entries. 37 | * We need to figure out where to put “unreleased” entries, how to handle merge conflicts, etc. 38 | * Leaning towards having an oncall or whoever merges things updating the changelog. 39 | * What if whenever we sync React master internally to Facebook (once a couple of weeks), we also generate the changelog? 40 | * This means that whoever does the sync has to do a little more work. 41 | * Combination of the batched approach + human discretion. 42 | * Will start this process with the next internal sync. 43 | 44 | ### Browser Tests 45 | 46 | * React attempts to normalize behavior across browsers but we don’t have any browser tests. ([#5703](https://github.com/facebook/react/issues/5703)) 47 | * We used to have them with Sauce Labs but they were super flaky and we removed them. ([#4393](https://github.com/facebook/react/pull/4393)) 48 | * Most of our tests aren’t tied to Jest and we should be able to get them running in the browser again. 49 | * Should we run the existing tests, or are there new types of things we want to test? 50 | * The types of things we care about with browser tests are often different. 51 | * Usually we don’t need Jest-isms like clearing the module registry in these tests as they only work with public API. 52 | * Example: Input selection should not jump to end of input when focusing a controlled input (or something like this). 53 | * Should we be worried tests will get flaky again? 54 | * We’ll start with a few very focused tests and see how it goes. 55 | * Let’s decide on a test runner and write some tests. 56 | * Let’s pick a recent regression and try to write a test for it. 57 | * [Jim](https://github.com/jimfb) will work on this. 58 | 59 | 60 | ### Attributes vs Properties 61 | 62 | * In React 15, we switched to using DOM attributes by default and using properties only in special cases. 63 | * This fixed a few issues but then introduced a few other issues. 64 | * While we patched over those regressions and 15 looks good, there is no consensus yet on whether this was the right call. 65 | 66 | #### Reasons to Use Attributes over Properties 67 | 68 | * Attributes currently match our desired behavior for more or less all supported props, including SVG. In the future properties might support more structured data but there’s nothing there we _currently_ want to take advantage of. 69 | * 0.14 already created HTML strings on initial render, and attributes are the closest alternative. 70 | * If we use attributes for everything we could just drop the whitelist completely (and treat only form components specially), which we may or may not want to do but it seems appealing. 71 | * For the specific regression that relying on attributes introduced ([not setting `value=""` on option tags](https://github.com/facebook/react/issues/6219)), we _can’t_ use properties because there is a semantic difference between `value=""` and no attribute, but `.value` is `''` in both cases. 72 | * Since we’re not invested into designing a rich API for React DOM props right now, having less maintenance burden in this area and making fewer decisions is appealing. 73 | 74 | #### Reasons to Use Properties over Attributes 75 | 76 | * Attributes seem to only match our wanted behavior for “metadata”, i.e. things that the DOM doesn’t actually really care about. The exception is SVG. 77 | * Attributes for initial render is a waste of resources (`toString` / `parse`) but semantically is OK. They also make sense for server rendering since the point of attributes is to provide an initial value. However this is not a good argument for why they should be used for values that change over time. 78 | * The addition of new elements and features leads to more controlled values and richer data types. Attributes are the legacy, not properties. 79 | * If there are any semantic differences that depend on attributes, we should flag those to standard committees. Then we can polyfill those using attributes, and then eventually remove the fix. 80 | * Maybe we should find someone to actually design this rich API mapping for React DOM props and maintain it. We aren’t busy with this now but this doesn’t mean the problem isn’t worthwhile. Hopefully one day it might be standardized in some form or just considered the canonical declarative bindings to the DOM. 81 | 82 | #### Conclusion 83 | 84 | * No conclusion yet. We plan to come back to this next week. 85 | * React 15 uses attributes. 86 | * The regressions in RCs appear fixed. 87 | 88 | #### Relevant Issues and Pull Requests 89 | 90 | * [#1431](https://github.com/facebook/react/issues/1431) 91 | * [#1510](https://github.com/facebook/react/pull/1510) 92 | * [#4618](https://github.com/facebook/react/issues/4618) 93 | * [#5666](https://github.com/facebook/react/pull/5666) 94 | * [#5680](https://github.com/facebook/react/pull/5680) 95 | * [#5907](https://github.com/facebook/react/pull/5907) 96 | * [#5966](https://github.com/facebook/react/issues/5966) 97 | * [#6119](https://github.com/facebook/react/issues/6119) 98 | * [#6219](https://github.com/facebook/react/issues/6219) 99 | * [#6228](https://github.com/facebook/react/pull/6228) 100 | * [#6406](https://github.com/facebook/react/pull/6406) 101 | 102 | ### Recent Pull Requests 103 | 104 | #### `ReactDOM.render()` return value being deprecated legacy ([#6400](https://github.com/facebook/react/pull/6400)) 105 | 106 | * It’s not deprecated yet and we don’t have a solid plan. But new code should avoid it. 107 | * We still rely on it heavily in our tests (basically all of them!) 108 | * We might need a separate reconciler for tests anyway. 109 | * We want to encourage people to move away from it because, if we implement incremental reconciler, we might not be able to always resolve nodes synchronously. 110 | * The only thing we know for sure is that this is a potential stumbling block going forward. 111 | 112 | #### [Sebastian](https://twitter.com/sebmarkbage) is moving some files from React Native to React ([#6338](https://github.com/facebook/react/pull/6338)) 113 | 114 | * This adds a new package called `react-native-renderer`. 115 | * It doesn’t block 15 and won’t need to wait until 16. 116 | * We might also split out the `react-dom-renderer` from `react-dom` in the future. 117 | * React Native repo will then contain components and the bridge, but not the parts that integrate tightly with React core. 118 | * Are all React Native engineers going to start pushing to the React repository now? 119 | * This is mostly stable React code, so shouldn’t churn much. 120 | * But yes, this is something we’ll have to figure out. 121 | * Waiting until Sebastian is back to provide an answer here. 122 | * Why are we doing this? 123 | * Ultimate goal is to make it so React core is separate from each of the renderers. 124 | * Wherever there’s overlap, we want to be able to iterate and ship independently. 125 | * A small change to React DOM should not necessarily trigger a new React release. 126 | * Versioning 127 | * We've started separating different packages, but they’re all still versioned at the same time. 128 | * Is this going to change? Yes, but not right now. 129 | * Again, we should be able to iterate on React core and downstream dependencies of React core independently. 130 | * Lots left to figure out here. 131 | 132 | 133 | ------------ 134 | 135 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/3). 136 | -------------------------------------------------------------------------------- /2016-04/april-21.md: -------------------------------------------------------------------------------- 1 | ## April 21 ([discuss](https://github.com/reactjs/core-notes/pull/8)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Dan](https://twitter.com/dan_abramov) (React) 7 | * [Jim](http://github.com/jimfb) (React) 8 | * [Paul](https://twitter.com/zpao) (React) 9 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 10 | * [Shayne](https://github.com/shayne) (React Native) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### 15.0 Post Mortem 14 | 15 | #### Release was pretty rocky 16 | * We didn’t have a cohesive enough story around what was to be included in the release. 17 | * Now that we have more dependants (RN, many teams internally and externally) it’s becoming an issue. 18 | * Examples of changes that we should have planned better: 19 | * [SVG attributes were passed through without a whitelist in RC1](https://github.com/facebook/react/pull/5714), then [we reverted this in RC2](https://github.com/zpao/react/commit/08fa7fe50707d4c7fe06861e0875b3fab00ea048). 20 | * We [switched to using attributes](https://github.com/facebook/react/pull/1510) by default but haven’t tested this as thoroughly as we should have, and it caused a few regressions, plus later it turned out that we didn’t all agree on this change ([Sebastian](https://twitter.com/sebmarkbage) was out of the loop). 21 | * Our default in the past has been to just work on everything individually. 22 | * [Ben](https://twitter.com/soprano) created a special GitHub group so that we can auto-subscribe all of us to some big picture issues. 23 | * We should have shipped an RC3. 24 | * But why did we get to RC2? 25 | * Having browser tests ([Jim](https://github.com/jimfb)) and planning releases ([Paul](https://twitter.com/zpao)) more thoroughly should fix this. 26 | * We should make the release process easier. 27 | * Right now there’s too much manual work involved. 28 | * If it was just one command, maybe we would have been more open to releasing RC3. 29 | 30 | ### Releasing 15.0.2 31 | 32 | * Either this Friday or early next week. 33 | * We merged some changes to [bring the `react-native-renderer` into the React repo](https://github.com/facebook/react/pull/6338) so we can change React internals more freely without breaking RN. 34 | * What else should get into 15.0.2? 35 | * [Fix for the `optgroup`s](https://github.com/facebook/react/pull/6442). 36 | * [CSS warning fix](https://github.com/facebook/react/pull/6458). 37 | * [TestUtils fix](https://github.com/facebook/react/pull/6362). 38 | * Right now we just run master on Facebook. 39 | * In six months, master and 15.x can diverge significantly. 40 | * We need to figure out a better story around syncing React with: 41 | * The Facebook website. 42 | * React Native. 43 | * [Paul](https://twitter.com/zpao) will write up how we’re going to do releases moving forward. 44 | 45 | ### Universal Components 46 | 47 | * [Nicolas](https://github.com/necolas) from Twitter created [React Native Web](https://github.com/necolas/react-native-web). 48 | * [Leland](https://github.com/lelandrichardson) from Airbnb maintains [a fork](https://github.com/lelandrichardson/react-native-web). 49 | * It is not clear how to create universal components. 50 | * For example, if you depend on `View` from `react-native`, you pull in the whole `react-native`. 51 | * How do you create a component that is renderable both in React Native and React Native Web? 52 | * Some registration system? 53 | * Injectable components? 54 | * Strings? 55 | * No conclusion, lots to think about. 56 | 57 | ### Adding Flow to React 58 | 59 | * Flow has helped engineers at Facebook immensely, and it might help us here: 60 | * We’d like to be more confident in the changes we want to make. 61 | * Might help newcomers be more comfortable making changes in the codebase. 62 | * [Ben](https://twitter.com/soprano) might experiment with adding it in some places, but we might want to hold off. 63 | * [Sebastian](https://twitter.com/sebmarkbage)’s concerns: 64 | * [The work on incremental reconciler](https://github.com/facebook/react/issues/6170) is going to be very invasive. 65 | * Forcing addition of Flow in places where it’s very hard to type should be a non-goal as there’s a lot of meta-programming. 66 | 67 | ### Who’s Working on What 68 | 69 | * [Ben](https://twitter.com/soprano): Working on some education material for React that could end up in the docs. 70 | * [Dan](https://twitter.com/dan_abramov): After a chat with Sebastian, [submitted another PR](https://github.com/facebook/react/pull/6549) for the future ReactPerf and DevTools revamp. 71 | * [Jim](http://github.com/jimfb): Mostly still fixing regressions. 72 | * [Paul](https://twitter.com/zpao): [Flat bundles](https://github.com/facebook/react/issues/6351), modernizing our build process, thinking about the new release process. 73 | * [Sebastian](https://twitter.com/sebmarkbage): Bug fixes to make React Native to work with React 15. 74 | * [Shayne](https://github.com/shayne): React Native relies on npm, so we need a better way of consuming npm modules internally at Facebook. 75 | 76 | 77 | ------------ 78 | 79 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/8). 80 | -------------------------------------------------------------------------------- /2016-04/april-28.md: -------------------------------------------------------------------------------- 1 | ## April 28 ([discuss](https://github.com/reactjs/core-notes/pull/10)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React / React Native) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Jim](http://github.com/jimfb) (React) 9 | * [Paul](https://twitter.com/zpao) (React) 10 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 11 | * [Shayne](https://github.com/shayne) (React Native) 12 | * [Tom](https://twitter.com/tomocchino) (React) 13 | 14 | ### Release Process and React Native 15 | 16 | #### We want to release to React Native more frequently 17 | 18 | * Can we push more frequently like we do with the Facebook website? 19 | * What if we ship React minor releases (or patch releases) every two weeks? 20 | * We should be using a public stable release of React (either a minor or patch) on the website. 21 | * This would coincide with the React Native release process. 22 | 23 | #### React Native users have way more third-party dependencies 24 | 25 | * These won’t be compatible with “pre-release” or bleeding edge versions of React. 26 | * The only people that use RC are folks that have something that was fixed (usually by them) in the RC. 27 | * Otherwise, upgrading so frequently is incredibly draining. 28 | 29 | #### Should we have feature flags, like Ember does? 30 | 31 | * Maybe this would help catch regressions earlier. 32 | * On the other hand, this causes an explosion of possible build configurations. 33 | 34 | #### If we’re releasing more frequently we need to be testing React Native more 35 | 36 | * We need to be testing the React release in React Native. 37 | * Everyone on the team needs to have a working React Native setup on their machines. 38 | 39 | #### Should we publish nightly releases? 40 | 41 | * Can React Native lock itself into whatever nightly it wants? 42 | * But we don’t want React Native to be pegged to a specific commit. 43 | * This is pretty much what we started doing in 15.x with `alpha` releases for patches. 44 | 45 | #### Current plan 46 | 47 | * Going to publish `alpha`s, which can be released as frequently as we want, even like 4 a day. 48 | * Once something is stable and we’re confident it's working in React Native, we’ll cut an actual release. 49 | * React Native and Relay always reference a stable release in their dependencies. 50 | 51 | #### What will our messaging be about alphas? 52 | 53 | * Alpha = use at your own risk. 54 | * If you depend on an alpha due to an urgent fix you need, pin it to a specific version. 55 | * Guidance should be “never publish anything to npm with an alpha dependency”. 56 | 57 | #### Open question: where does the breaking change development happen? 58 | 59 | * Are we on `15.1.0-dev` or `16.0.0-dev`? 60 | * Do we merge breaking changes to master? 61 | * Currently we cherry-pick commits to `15-stable` but this is frustrating because 99% changes are not breaking. 62 | * Need to discuss more, no conclusion yet. 63 | 64 | ### Experimenting with `StyleSheet.create()` on the web 65 | 66 | * [Christopher](http://twitter.com/vjeux) continues experimenting with `StyleSheet.create()` on the Facebook website codebase. 67 | * He made a proof of concept compiling these calls into CSS sheets compatible with Facebook internal asset pipeline. 68 | * Maintaining correct specifity with `StyleSheet.create()` is not an easy problem, but it may be solved by throwing errors early during development when there is a potential specificity issue, and providing a clear way for the developer to work around it. 69 | * Compiling `StyleSheet.create()` to emitting real CSS files through our internal asset pipeline lets us move a bit closer to experimenting with real inline styles without having to bet on them right now. 70 | * Nothing is certain, and Christopher will continue experimenting this month. 71 | * If it doesn’t turn out to be valuable, this will not make it into React! Don’t get too excited. 72 | 73 | ------------ 74 | 75 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/10). 76 | -------------------------------------------------------------------------------- /2016-05/may-05.md: -------------------------------------------------------------------------------- 1 | ## May 5 ([discuss](https://github.com/reactjs/core-notes/pull/13)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Dan](https://twitter.com/dan_abramov) (React) 7 | * [Jim](http://github.com/jimfb) (React) 8 | * [Paul](https://twitter.com/zpao) (React) 9 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 10 | * [Shayne](https://github.com/shayne) (React Native) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### ReactPerf Rewrite 14 | 15 | * [Dan](https://twitter.com/dan_abramov) got his rewrite of `ReactPerf` [merged into React master](https://github.com/facebook/react/pull/6647). 16 | * It is mostly functionally identical to the old one but is written in a more maintainable way. 17 | * At Facebook, we don’t use the console `ReactPerf` API much so we’ll need community help testing this. 18 | * There is a corresponding [React Native PR](https://github.com/facebook/react-native/pull/7283) that depends on these changes. 19 | * The change removes `ReactPerf.measure()` wrappers and instead emits events (e.g. `onBeginLifeCycleTimer`). 20 | * Related PRs: [#6549](https://github.com/facebook/react/pull/6549), [#6612](https://github.com/facebook/react/pull/6612), [#6633](https://github.com/facebook/react/pull/6633), [#6046](https://github.com/facebook/react/pull/6046). 21 | * It will most likely go into `15.1.0-alpha` early next week. 22 | 23 | ### TestUtils and Enzyme 24 | 25 | * Airbnb’s [Enzyme](https://github.com/airbnb/enzyme) is well maintained and supported. 26 | * Our [`TestUtils`](https://facebook.github.io/react/docs/test-utils.html) are not in a great shape, and most people prefer Enzyme. 27 | * Should Enzyme become the official `TestUtils`? 28 | 29 | #### Challenges 30 | 31 | * Ideally we want test runner to be a separate renderer. 32 | * Tests should run consistently and often synchronously so we don’t want to run them with [incremental reconciler](https://github.com/facebook/react/issues/6170). 33 | * We have no official renderer APIs yet so without `TestUtils` Enzyme would have to rely on React internals. 34 | 35 | #### Risks 36 | 37 | * If Enzyme is abandoned, we will have to maintain it. 38 | * Not a big deal because this is pretty much our situation with `TestUtils` now. 39 | * Recommending it as an official solution might raise questions about “official solutions” to other problems. 40 | * (e.g. routing, state management) 41 | * We don’t have guidelines for recommending something as an official solution. 42 | * No conclusion yet, needs more discussion. 43 | 44 | ### Server Rendering 45 | 46 | * After thinking more about incremental reconciliation, [Sebastian](https://twitter.com/sebmarkbage) has some renewed interest in server rendering. 47 | * Whatever feature server rendering wants, it’s a good feature to have on the client as well. 48 | * For example, if you have a component that’s unlikely to change: 49 | * Currently you have all those React internal instances in memory. 50 | * But if you remove those, and are able to recover… 51 | * It’s just like reviving a server rendered tree on the client. 52 | * Current behavior for rehydration after server rendering: 53 | * It re-renders everything on the client to a string to verify the checksum, then throws it out. 54 | * If it’s the same, and we need the node or instance for any reason, at that point we climb the tree and figure out what instance it corresponds to lazily. 55 | * It doesn’t fix any inconsistencies it finds as it traverses back up. 56 | * This is what [@aickin](https://github.com/aickin) is trying to change in his [pull request](https://github.com/facebook/react/pull/6618). 57 | * What does [#6618](https://github.com/facebook/react/pull/6618) help with? 58 | * We can loosen constraints on validation. 59 | * Markup doesn’t have to be character for character equivalent. 60 | * [Ben](https://twitter.com/soprano) has [concerns](https://github.com/facebook/react/pull/6618#issuecomment-217321531) about it. 61 | 62 | ### CSS Fallback Values 63 | 64 | * We don’t have a way of letting people specify fallback values for vendor prefixes. 65 | * People ask for something like this: `display: ['-webkit-box', '-moz-box', '-ms-flexbox', '-webkit-flex']`. 66 | * Using arrays for this precludes supporting something like `margin: [0, 0]` in the future. 67 | * We could use an opaque data structure for this, e.g. `ReactDOM.CSS.multi('-webkit-box', '-moz-box', ...)`. 68 | * There’s a proof of concept in [#6701](https://github.com/facebook/react/pull/6701). 69 | * Still needs more bikeshedding on the name but the idea is sound. 70 | * We might want to look at autoprefixing again the next time we approach inline styles in the future. 71 | 72 | ------------ 73 | 74 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/13). 75 | -------------------------------------------------------------------------------- /2016-05/may-12.md: -------------------------------------------------------------------------------- 1 | ## May 12 ([discuss](https://github.com/reactjs/core-notes/pull/14)) 2 | 3 | ### Attendees 4 | 5 | * [Alex](https://twitter.com/alex_frantic) (React Native) 6 | * [Ben](https://twitter.com/soprano) (React) 7 | * [Christoph](https://twitter.com/cpojer) (Jest) 8 | * [Christopher](https://twitter.com/vjeux) (React Native) 9 | * [Dan](https://twitter.com/dan_abramov) (React) 10 | * [Jim](http://github.com/jimfb) (React) 11 | * [Paul](https://twitter.com/zpao) (React) 12 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 13 | * [Shayne](https://github.com/shayne) (React Native) 14 | * [Tom](https://twitter.com/tomocchino) (React) 15 | 16 | ### Inline Styles Update 17 | 18 | * [Christopher](https://twitter.com/vjeux) is going on a parental leave and will continue [his experiments](https://github.com/reactjs/core-notes/blob/master/2016-04/april-28.md#experimenting-with-stylesheetcreate-on-the-web) in July. 19 | * Don’t forget that this is tied to Facebook build asset pipeline, and is not directly applicable to React. 20 | * However lessons learned from this work may influence our thinking about inline styles in the future. 21 | 22 | ### Error Messages 23 | 24 | * People have been complaining about [the lack of error messages in production React](https://github.com/facebook/react/issues/2686). 25 | * Many of them aren’t actionable anyway, but some [can be useful](https://github.com/facebook/react/issues/2686#issuecomment-218017606). 26 | * We might want to consider an [error code system](https://github.com/facebook/react/issues/2686#issuecomment-209171272). 27 | 28 | #### Error Code System 29 | 30 | * Babel transform annotates every callsite with a number that’s known statically. 31 | * Sentry (and others!) can look up that number in a map. 32 | * A new intern will be working on this! 33 | 34 | ### New Intern! 35 | 36 | * Keyan will be working on the React team as an intern. 37 | * [Ben](https://twitter.com/soprano) will be mentoring him. 38 | * The plan is for him to work on the error code system described above. 39 | * Another thing he might work on is a “yellow box” a la React Native. 40 | 41 | #### Yellow Box 42 | 43 | * Where should it go? fbjs? 44 | * Could be a more effective vector for communication between the React core team and users of React than console warnings. 45 | * To be practical, we would need to have warning levels and some way of suppressing them. 46 | * This is just an idea, the details would need to be fleshed out. 47 | 48 | ### `shouldComponentUpdate()` Breaks Context 49 | 50 | * A [longstanding issue](https://github.com/facebook/react/issues/2517) with a very long thread. 51 | * [Sebastian](https://twitter.com/sebmarkbage) has been thinking about this (just this morning!) 52 | * With the [incremental reconciler](https://github.com/facebook/react/issues/6170), we think we’ll solve this. 53 | 54 | #### Can We Fix It Now? 55 | 56 | * It will make things a lot more inefficient. 57 | * Only some libraries use context for dynamically updating values, but enabling deep subscriptions by default will hurt performance for everyone. 58 | 59 | #### Hacky Workaround 60 | 61 | * For now, React Router 3.0 adds a hacky [workaround](https://github.com/reactjs/react-router/blob/5f3387a91d427aec1368e68cd9605797aa076bb7/modules/ContextUtils.js). 62 | * [@taion](https://github.com/taion) plans to pull it out in a generic module for other affected libraries. 63 | * Nobody is really happy about it, but hopefully it should be easy to pull it out later. 64 | * It [uses mixins](https://github.com/reactjs/react-router/issues/3439#issuecomment-217887475) so it’s easier to pull it out, and it doesn’t trash React DevTools view. 65 | * Hopefully eventually React fixes this, and React Router can unpublish stop using that package. 66 | 67 | ### Incremental Progress vs Long-Term Vision 68 | 69 | * Long-term ideas and features often block incremental and external contributions. 70 | * We might want to spend more time just supporting features the community is asking for, even if we don't use them. 71 | * One concern is that the proposed solution often will leave us in a worse place than where we were before. 72 | * This is often not obvious in the beginning, and unfortunately a lot of work may get done before we realize this. 73 | 74 | #### Focus on One Thing 75 | 76 | * Maybe as a team we can focus on one area at a time. 77 | * For example, let’s just do one thing, do it well, and ship it. 78 | * Better than letting ourselves get overwhelmed. 79 | 80 | #### Avoid Wasted Effort 81 | 82 | * We can focus on external needs, but we also need to make sure that external folks are willing to support our needs internally. 83 | * This requires that we better communicate our needs and priorities. 84 | * There’s a long unwritten list of constraints, and we often reactively provide that list. 85 | * But it’s hard for contributors to know before they work on their big PR what that list is. 86 | 87 | #### RFCs 88 | 89 | * We should adopt an RFC process! 90 | * Long discussions should start before folks submit a PR. 91 | * In some cases, they can start after, but not in the PR itself. 92 | * Let’s use the [Rust](https://github.com/rust-lang/rfcs/blob/master/libs_changes.md#is-an-rfc-required) / [Ember](https://github.com/emberjs/rfcs#when-you-need-to-follow-this-process) RFC process. 93 | 94 | ### Snapshot Testing 95 | 96 | * [Cristian](https://github.com/kentaromiura) in London is working on [snapshot testing](https://github.com/facebook/jest/pull/1000) in Jest. 97 | * [Ben](https://twitter.com/soprano) has been prototyping a full React test renderer that can render everything both on React Native and DOM. 98 | * Unlike shallow renderer, it is stateful and renders deeply. 99 | * Things won’t actually render to React Native or to the DOM, but rather to an intermediate representation. 100 | * This will give us the ability to diff representations. 101 | * (Basically we’re pretty-printing JSX and then doing textual diffs.) 102 | * It is not clear if the intermediate representation should include information about composite components (the “DevTools tree”). 103 | * Maybe this could be configurable. 104 | 105 | ------------ 106 | 107 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/14). 108 | -------------------------------------------------------------------------------- /2016-05/may-19.md: -------------------------------------------------------------------------------- 1 | ## May 19 ([discuss](https://github.com/reactjs/core-notes/pull/15)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React Native) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Jim](http://github.com/jimfb) (React) 9 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 10 | * [Paul](https://twitter.com/zpao) (React) 11 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 12 | * [Tom](https://twitter.com/tomocchino) (React) 13 | 14 | ### `createClass()` vs ES2015 Classes 15 | 16 | #### Why Use Classes? 17 | 18 | * `createClass()` API feels outdated, and can be implemented entirely in userland if needed. 19 | * ES6 classes are less of an API, possibly simpler. 20 | * ES6 classes are friendlier to static analysis. 21 | * ES6 classes offer performance improvements in large apps. 22 | * We are in the business of UI components, not type systems. 23 | 24 | #### What’s Holding Us Back? 25 | 26 | ##### Autobinding 27 | 28 | * [Class properties](https://github.com/jeffmo/es-class-fields-and-static-properties) solve this. 29 | * However they’re not moving forward at TC39 yet as [Jeff](https://github.com/jeffmo) is busy preparing for React Europe. 30 | * Downside: nobody wants experimental syntax in the documentation. 31 | * We could just always bind in constructor in the documentation. 32 | 33 | ##### Mixins 34 | 35 | * A lot of components on Facebook website still use mixins, but mostly the same ones. 36 | * If we decided to deprecate `createClass` in the future, we would need to fix them first. 37 | * Possible temporary workaround: apply them on top of ES6 class like [react-mixin](https://github.com/brigand/react-mixin) does. 38 | 39 | #### Next Steps 40 | 41 | * We should update the documentation to use ES6 classes and functional components wherever possible. 42 | * Eventually we should deprecate `createClass`, possibly move it into a separate package. 43 | * We need to have a good solution for folks who don’t want to use a transpiler. 44 | 45 | ### Separating Out `PropTypes` 46 | 47 | * [Jordan](https://twitter.com/ljharb) and some Airbnb folks asked about separating `PropTypes` into a generic validation library. 48 | * One concern might be that as a separate project `PropTypes` could become incompatible (as a type system) with Flow or TypeScript. 49 | * Internally long term we’d like to avoid `PropTypes` usage and rely on static typing instead. 50 | * Some checks can’t easily be expressed statically (e.g. ranges or colors). 51 | * Conclusion: anyone can take `PropTypes` code and put it on npm. 52 | * If it enforces a generic enough contract, we might try to replace `PropTypes` with it in the future, but no guarantees. 53 | * Our internal plan will be to focus on ES6 classes and Flow. 54 | 55 | ### New Release Proposal 56 | 57 | * 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). 58 | * 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. 59 | * We will release React versions every two weeks, a couple of days before React Native RCs. 60 | * We might start using [Lerna](https://lernajs.io), it works great for Babel. 61 | * Do we ship from a branch or from master? No conclusion yet. 62 | 63 | ------------ 64 | 65 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/15). 66 | -------------------------------------------------------------------------------- /2016-05/may-26.md: -------------------------------------------------------------------------------- 1 | ## May 26 ([discuss](https://github.com/reactjs/core-notes/pull/17)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React Native) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Jim](http://github.com/jimfb) (React) 9 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 10 | * [Paul](https://twitter.com/zpao) (React) 11 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 12 | * [Shayne](https://github.com/shayne) (React Native) 13 | * [Tom](https://twitter.com/tomocchino) (React) 14 | 15 | ### ES2016 Classes 16 | 17 | #### Class Property Initializers ([proposal](https://github.com/jeffmo/es-class-fields-and-static-properties)) 18 | 19 | * ES classes for React components don’t feel good without them. 20 | * We haven’t used them internally at Facebook enough to push externally. 21 | * For now, we’ll push for more internal adoption of ES classes. 22 | * We don’t want to hinder the proposal by pushing too hard for it now. 23 | * After the proposal is further along, we can update our internal code and start pushing externally. 24 | 25 | #### Documentation and Tutorial 26 | 27 | * We need to figure out how to make the docs reflect the fact that you can use either `createClass` or ES classes. 28 | * Proposal: the docs will continue to show `createClass` as the default, but will include a switcher to show examples using classes. 29 | * Eventually, we will flip the default. 30 | * In the tutorial we’ll start out introducing functional components (using function declarations). 31 | * [Dan](https://twitter.com/dan_abramov) and [Paul](https://twitter.com/zpao) will work on this. 32 | 33 | #### What About Mixins? 34 | 35 | * Technically you can use [this approach](https://www.npmjs.com/package/es6-react-mixins) for mixins with ES classes. 36 | * We won’t officially recommend it though because we think existing use cases for mixins have better solutions. 37 | * We’ll start by getting rid of mixins in the Facebook codebase. 38 | * Then we’ll write a page detailing how to get rid of different kinds of mixins. 39 | 40 | #### Higher Order Components ([article](https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750)) 41 | 42 | * They solve some of the mixin use cases. 43 | * We should post about them in the official React blog and/or documentation. 44 | * They have their own problems, such as not proxying methods. 45 | * One solution would be to [allow forwarding callback refs](https://github.com/facebook/react/issues/4213). 46 | * Not clear if we want this, but it would make higher order components more convenient to use. 47 | 48 | ### `ReactTestUtils` and Incremental Reconciler 49 | 50 | * [Incremental reconciler](https://github.com/facebook/react/issues/6170) is going to be asynchronous. 51 | * However `ReactTestUtils.renderIntoDocument()` is synchronous. 52 | * It is not entirely clear if test utils should emulate a simpler always-sync environment, or real world. 53 | 54 | ### Error Codes 55 | 56 | * [Keyan](https://twitter.com/keyanzhang) continues work on the PRs that let people decode error messages: 57 | - [#6874](https://github.com/facebook/react/pull/6874) 58 | - [#6882](https://github.com/facebook/react/pull/6882) 59 | 60 | ------------ 61 | 62 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/17). 63 | -------------------------------------------------------------------------------- /2016-06/june-02.md: -------------------------------------------------------------------------------- 1 | ## June 2 ([discuss](https://github.com/reactjs/core-notes/pull/18)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Jim](http://github.com/jimfb) (React) 7 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 8 | * [Paul](https://twitter.com/zpao) (React) 9 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 10 | * [Shayne](https://github.com/shayne) (React Native) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### Getting Rid of `PureRenderMixin` 14 | 15 | * This is one of the most commonly used mixins. 16 | * We need to have a good story around applying it to classes and SFCs (**stateless functional components**). 17 | * Let’s consider a few alternatives. 18 | 19 | #### Proposal 1: `PureComponent` and heuristics for SFCs 20 | 21 | * Create `React.PureComponent` base class (kinda like a class with `PureRenderMixin`). 22 | * Make SFCs “inherit” their purity from the closest class-based parent. 23 | * This works because if the class above is pure, SFC wouldn’t re-render anyway. 24 | * Implemented in [#6914](https://github.com/facebook/react/pull/6914) with some additional explanation [here](https://github.com/facebook/react/pull/6914#issuecomment-222364942). 25 | 26 | ##### Concerns 27 | 28 | * Any heuristics based model will probably not work in 100% of cases, and could cause confusion. 29 | * If you pass children through, you don’t know anything about them, including whether they use mutation. 30 | 31 | ##### Potential Mitigations 32 | 33 | * Warn if a `PureComponent` takes in a child element (or child element which changes). 34 | * In dev mode, do dry-run reconciliation past all `shouldComponentUpdate`s and warn if `shouldComponentUpdate` lied to React. 35 | 36 | #### Proposal 2: SFCs Always Shallowly Compare Props 37 | 38 | * Effectively a `PureRenderMixin` on every SFC. 39 | 40 | ##### Concerns 41 | 42 | * Means that component authors generally can’t / shouldn’t use SFCs because `PureRenderMixin` shouldn’t be used with components that take children. 43 | * Intuitively, people expect SFCs to behave like functions. The bailout would be surprising, and there isn’t a particularly good way of discovering why the function isn’t behaving like a normal JavaScript function. 44 | * Performance. It’s not clear that adding `PureRenderMixin` to every SFC would actually improve overall performance (because it means extra reads/compares, retaining objects longer and into subsequent GC generations, etc). 45 | 46 | #### Proposal 3: `createPureElement` 47 | 48 | * Provide some flag on components at the calling side to denote that they should be pure. 49 | * This would tell React to effectively “use `PureRenderMixin`” on that particular instance, *not all instances*. 50 | * Many syntax possibilities: `pure={true}`, or `<*Component />`, `React.createPureElement()`, etc. 51 | 52 | ### ES Class Progress 53 | 54 | * [Ben](https://twitter.com/soprano) is leading the effort to port Facebook codebase to ES classes. 55 | * We plan to enable property initializer syntax internally, and codemod all methods except lifecycles to it. 56 | 57 | ------------ 58 | 59 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/18). 60 | -------------------------------------------------------------------------------- /2016-06/june-09.md: -------------------------------------------------------------------------------- 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 | * After that, getting parity with the existing APIs. 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 | * Mixins: if a component _only_ uses `PureRenderMixin`, it will be converted to an ES6 class that extends [`React.PureComponent`](https://github.com/facebook/react/pull/6914). Otherwise it will be left untouched for now. 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). 77 | -------------------------------------------------------------------------------- /2016-06/june-23.md: -------------------------------------------------------------------------------- 1 | ## June 23 ([discuss](https://github.com/reactjs/core-notes/pull/21)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Dan](https://twitter.com/dan_abramov) (React) 7 | * [Jim](http://github.com/jimfb) (React) 8 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 9 | * [Paul](https://twitter.com/zpao) (React) 10 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### Update on `createClass` → ES classes 14 | 15 | * [Dan](https://twitter.com/dan_abramov) finished working on a codemod for internal Facebook code that converts 800 files to remove one of the common mixins we used. 16 | * While doing so, Dan found an issue with inconsistent order of resolving refs during updates. 17 | * Ideally code should not depend on ref resolution order. 18 | * Unfortunately some Facebook components rely on it so for now we [fixed this in React](https://github.com/facebook/react/pull/7101). 19 | 20 | ### JSON Test Renderer 21 | 22 | * [Ben](https://twitter.com/soprano) added a [new test renderer intended for snapshot testing](https://github.com/facebook/react/pull/6944). 23 | * For now, we don’t document it, as we might want to change the API. 24 | * We *don’t* want people to rely on the renderer output or test against JSON. 25 | * This renderer is *only* intended for comparing snapshots, not analyzing them. 26 | * It is also not clear how to dispatch events with it. 27 | * Jest plans to add a guide on using it later on [its blog](https://facebook.github.io/jest/blog/) after it is more stable. 28 | 29 | ### Update on 15.2.0 30 | 31 | * We cut the RC last week and React Native RC uses it. 32 | * It contains a lot of commits but not too many substantial changes. 33 | * Will be released within two weeks. 34 | 35 | ### Update on Release Process 36 | 37 | * [Paul](https://twitter.com/zpao) started writing a maintainer’s guide to document the entire release process. 38 | * He ran the 15.2.0 RC release using a new tool he’s working on. 39 | * The process relies on us assigning semver labels (e.g. “major”, “patch”) but not specific milestones. 40 | * The tool will automate the release process based on those labels. 41 | * This should enable us to cut releases more often and let other people (e.g. React Native members) do it. 42 | 43 | ### Fast Path 44 | 45 | * This is a hypothetical optimization [Jim](http://github.com/jimfb) wanted to try. 46 | * What if we took functional components that render only to DOM components and precompiled them to fast path “templates”? 47 | * This could be an optimization specific to the DOM renderer. It would use `document.createElement` or `cloneNode()`. 48 | * However most components use other components so it’s unclear if there are any benefits to doing this. 49 | * [Sebastian](https://twitter.com/sebmarkbage) had a more generic idea about component folding but it requires whole program analysis. 50 | * There is nothing conclusive here and this is not something we actively investigate. 51 | 52 | ### Testing with Feature Flags 53 | 54 | * We currently test server rendering by enabling the client side renderer to do server side rendering ([we set `useCreateElement` to `false` and re-run the suite](https://github.com/facebook/react/blob/24dfb56113a214d98f29f69e2c26f67d7e947067/.travis.yml#L80-L81)). 55 | * We’d like to decouple client side from server side rendering. 56 | * [Sebastian](https://twitter.com/sebmarkbage)’s experimental “Fiber” reconciler does not yet support server rendering. 57 | * We need to split out server rendering before switching to Fiber. 58 | 59 | ### Update on [Fiber](https://github.com/facebook/react/pulls?q=is%3Apr+fiber+is%3Aclosed) 60 | 61 | * This is [Sebastian](https://twitter.com/sebmarkbage)’s work on [new core algorithm](https://github.com/facebook/react/issues/6170). 62 | * Its main goal is to render tree in chunks to avoid dropping frames on large updates. 63 | * It sort of works but far from feature parity. 64 | * Need to add support for a lot of things: lifecycle, refs, state. 65 | * It should be possible to keep `ReactDOM` and `ReactDOMFiber` separate. 66 | * It would be great to test it in isolation on a single product. 67 | 68 | ### Flow with Property Initializers 69 | 70 | [Jeff](https://twitter.com/lbljeffmo) will release a Flow version that infers the types from the initializers so we can write the types inline instead of specifying the type of the whole expression: 71 | 72 | ```js 73 | class Foo { 74 | doStuff = (x: number): boolean => { 75 | return true; 76 | }; 77 | } 78 | ``` 79 | 80 | ------------ 81 | 82 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/21). 83 | -------------------------------------------------------------------------------- /2016-06/june-30.md: -------------------------------------------------------------------------------- 1 | ## June 30 ([discuss](https://github.com/reactjs/core-notes/pull/22)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Dan](https://twitter.com/dan_abramov) (React) 7 | * [Jim](http://github.com/jimfb) (React) 8 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 9 | * [Paul](https://twitter.com/zpao) (React) 10 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### Fiber Demo 14 | 15 | * If you missed what Fiber is, [look here](https://github.com/reactjs/core-notes/blob/master/2016-06/june-23.md#update-on-fiber). 16 | * Not very exciting.. but it can render a `
`! 17 | * Basically this is all that [Sebastian](https://twitter.com/sebmarkbage) showed us so far. 18 | * You can find the demo [here](https://github.com/facebook/react/blob/24dfb56113a214d98f29f69e2c26f67d7e947067/examples/fiber/index.html) but you’d need to compile React DOM to point to the [fiber version](https://github.com/facebook/react/blob/24dfb56113a214d98f29f69e2c26f67d7e947067/src/renderers/dom/fiber/ReactDOMFiber.js). 19 | 20 | ### Update on `createClass` → ES classes 21 | 22 | * We are moving towards not using `createClass` in the internal Facebook components. 23 | * [Keyan](https://twitter.com/keyanzhang) is working on an open source [codemod](https://github.com/reactjs/react-codemod/pull/54) to automate the transition. 24 | * The codemod converts `createClass` calls to ES classes with experimental [property initializers](https://github.com/jeffmo/es-class-fields-and-static-properties) proposal and Flow. 25 | * We *don’t* officially recommend this yet because the proposal has not advanced yet but we want to dogfood it internally. 26 | * There are more things to figure out with Flow (e.g. we might need to annotate state properties). 27 | * [Dan](https://twitter.com/dan_abramov) ran the codemod that removes one very common mixin we had, so now we have more convertible classes. 28 | * It is essential that we add some version of [`PureComponent`](https://github.com/facebook/react/pull/6914) to React because a lot of components use `PureRenderMixin`. 29 | 30 | ### `React.PureComponent` 31 | 32 | #### Naming 33 | 34 | * We’ve been assuming we’d call it `React.PureComponent`. 35 | * However “pure” really means something different in computer science. 36 | * What we try to express is that component `props` are immutable so the output is safe to memoize. 37 | * Other suggestions: `MemoizedComponent`, `MemoizableComponent`. 38 | * It’s hard to spell! 39 | * We *don’t* want people to use it everywhere so more complicated name might be fine. 40 | * We can bikeshed on this forever. 41 | 42 | #### Heuristics 43 | 44 | * It seems that [proposed heuristic generated a lot of confusion](https://github.com/facebook/react/pull/6914) and [potential issues](https://github.com/facebook/react/pull/6914#issuecomment-229574637). 45 | * We can drop the heuristic from the proposal and just get the class in. Then decide later. 46 | 47 | ### Splitting [Addons](https://facebook.github.io/react/docs/addons.html) 48 | 49 | * After the internal `createClass` deprecation, can we drop the addons? 50 | * We [haven’t](https://github.com/facebook/react/pulls?q=is%3Apr+reacttransitiongroup+is%3Aclosed) been maintaining `ReactTransitionGroup` and other addons well. 51 | * We should transfer ownership to folks that are actually relying on them. 52 | * Almost everything can be decoupled except `Perf` and `TestUtils`. 53 | * This should happen before [flat bundling](https://github.com/facebook/react/issues/6351). 54 | * Should we move `React.createFragment` into React? 55 | - No, this was an upgrade path, shouldn’t need to use it anymore. 56 | - It could have been the way you specify render methods without a single return value but we didn’t implement this. 57 | * [Paul](https://twitter.com/zpao) and [Dan](https://twitter.com/dan_abramov) will come up with a plan for each addon. 58 | 59 | ### React Hot Loader 3 60 | 61 | * It is popular in the community but the last stable version doesn’t work with functional components. 62 | * There is a new version that solves these problems but it isn’t quite stable yet. 63 | * [Dan](https://twitter.com/dan_abramov) will take a week to fix a few issues and release a stable version with docs. 64 | 65 | ### Releasing 15.2.0 66 | 67 | * [Paul](https://twitter.com/zpao) planned to release today. 68 | * [Dan](https://twitter.com/dan_abramov) noticed it would be better to [deduplicate](https://github.com/facebook/react/issues/7152) the new DOM unknown attribute warning. 69 | * We will let the community fix it and then cut 15.2.0. 70 | * [Jim](http://github.com/jimfb) wrote about the reasons and the strategies for fixing this warning [in the related gist](https://gist.github.com/jimfb/d99e0678e9da715ccf6454961ef04d1b). 71 | * Some useful discussions about this change: [erikras/redux-form#1249](https://github.com/erikras/redux-form/issues/1249), [Hacker0x01/react-datepicker#517](https://github.com/Hacker0x01/react-datepicker/issues/517). 72 | * We won’t do a blog post about this release (and about most patch and minor releases in general). 73 | * Instead, you can find changes in the [changelog](https://github.com/facebook/react/blob/master/CHANGELOG.md#1520-july-1-2016). 74 | 75 | ------------ 76 | 77 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/22). 78 | -------------------------------------------------------------------------------- /2016-07/july-07.md: -------------------------------------------------------------------------------- 1 | ## July 07 ([discuss](https://github.com/reactjs/core-notes/pull/23)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 9 | * [Paul](https://twitter.com/zpao) (React) 10 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### Fragments 14 | 15 | * We don’t currently allow returning multiple elements from `render()` method. 16 | * This has been a [long requested feature](https://github.com/facebook/react/issues/2127) in the community. 17 | * We generally agree that it should be implemented but we found it to be hard with our existing architecture. 18 | 19 | #### Existing Solutions 20 | 21 | * There exists a [fork](https://github.com/facebook/react/issues/2127#issuecomment-216401555) that implements fragments but we don’t want to take this implementation. 22 | * It introduces them only for React DOM which would make React features inconsistent across renderers. 23 | * It also introduces some complexity we would like to avoid because we might start breaking other things with it. 24 | 25 | #### Our Plans 26 | 27 | * [Fiber](https://github.com/reactjs/core-notes/blob/master/2016-06/june-23.md#update-on-fiber) supports fragments but it’s far from done. 28 | * We will include work on fragments in our plan for the second half of 2016. 29 | * Since we want this feature anyway, we can implement it in existing reconciler independently of Fiber. 30 | 31 | ### Build Size 32 | 33 | * We think that React provides good value for its build size (~45kB min+gzip). 34 | * However we understand everybody has different constraints, especially with small apps. 35 | * We intend to be [more mindful](https://github.com/facebook/react/issues/7205) of the build size to avoid accidental regressions. 36 | 37 | #### Rollup 38 | 39 | * [Keyan](https://twitter.com/keyanzhang) is investigating using [Rollup](http://rollupjs.org/) for our UMD builds. ([#7178](https://github.com/facebook/react/pull/7178)) 40 | * After [#7178](https://github.com/facebook/react/pull/7178) is merged, the minified post-gzip size will reduce by 14%. (46kB → 39kB) 41 | * For now, we will use [a hack](https://github.com/facebook/react/pull/7178#issuecomment-230379738) to transpile CommonJS to ES Modules so Rollup understands them. 42 | * Longer term, we’d like to use ES Modules in the source but Facebook internal bundlers don’t understand them yet. 43 | 44 | #### Event System 45 | 46 | * [Dan](https://twitter.com/dan_abramov) asked why the event system is so large. 47 | * It accounts for a noticeable chunk of React build size. 48 | * Looking at other “React-like” libraries, no one has an event system like ours. Why? 49 | 50 | ##### Why We Need It 51 | 52 | * The intention was to normalize events with weird behavior like `mouseenter` or `focus` across browsers. 53 | * This lets component authors not worry about inconsistencies with bubbling and input events, making ecosystem better. 54 | * The React Native gesture handling system is also built around it. 55 | * The browsers have improved, so we will keep re-evaluating it once in a while, but for now we find it useful. 56 | 57 | ##### What We Can Improve 58 | 59 | * It is overabstracted, and we can simplify code by baking support for some [“plugins”](https://github.com/facebook/react/tree/1a0e3a32150468223d6f9fd0125db0f8503b76d6/src/renderers/dom/client/eventPlugins) right into it. 60 | * There is some code duplication we can reduce in [the event whitelist](https://github.com/facebook/react/blob/1a0e3a32150468223d6f9fd0125db0f8503b76d6/src/renderers/dom/client/eventPlugins/SimpleEventPlugin.js). 61 | * Some weird patterns like [`keyOf()`](https://github.com/facebook/react/blob/1a0e3a32150468223d6f9fd0125db0f8503b76d6/src/renderers/dom/client/eventPlugins/SimpleEventPlugin.js#L40-L41) exist to be compatible with [GCC](https://developers.google.com/closure/compiler/). Perhaps we could find another way to fix this? 62 | 63 | ------------ 64 | 65 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/23). 66 | -------------------------------------------------------------------------------- /2016-07/july-21.md: -------------------------------------------------------------------------------- 1 | ## July 21 ([discuss](https://github.com/reactjs/core-notes/pull/24)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 9 | * [Paul](https://twitter.com/zpao) (React) 10 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 11 | * [Tom](https://twitter.com/tomocchino) (React) 12 | 13 | ### Hackathon 14 | 15 | * Team members worked on tangential/random projects last week. 16 | * [Sebastian](https://twitter.com/sebmarkbage) showed a demo of text layout in JS. 17 | * [Dan](https://twitter.com/dan_abramov) and [Christopher](https://twitter.com/vjeux) introduced [Create React App](https://github.com/facebookincubator/create-react-app). 18 | 19 | ### Update on `createClass` Codemod 20 | 21 | * We are continuing work on moving Facebook.com codebase away from `createClass`. 22 | * Discovered an issue with automocking of bound functions working differently, fixing the internal tests manually. 23 | * [`PureComponent`](https://github.com/facebook/react/pull/7195) didn’t quite work in Flow, fixed in [0.30.0](https://github.com/facebook/flow/releases/tag/v0.30.0). 24 | * Plan to run the [`createClass` codemod](https://github.com/reactjs/react-codemod#class) on Facebook.com codebase this weekend. 25 | * It touches 1/7 of all files in the Facebook.com JS codebase! 26 | 27 | ### Introducing [Create React App](https://github.com/facebookincubator/create-react-app) 28 | 29 | * Started at a hackathon last week. 30 | * Ready to release tomorrow with a live stream. 31 | * Using `import` for CSS is somewhat controversial. 32 | * [Ben](https://twitter.com/soprano) is concerned that it is non-standard. 33 | * [Dan](https://twitter.com/dan_abramov) and [Christopher](https://twitter.com/vjeux) think upsides of using one bundler for all assets outweigh the downsides. 34 | * We’ll add a note to the [howto](https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#adding-a-stylesheet) explaining how this works, and that it is not required for React. 35 | * We don’t have this problem at Facebook because we have a custom CSS pipeline, but we aren’t entirely happy with it either. 36 | 37 | ### React Release Manager 38 | 39 | * [Paul](https://twitter.com/zpao) is getting close to finishing React Release Manager. 40 | * The goal is to make it easy for anyone to release a new version of React. 41 | * It automates all the steps we are doing before every release so React Native folks or community members can cut releases. 42 | * It has a slick interactive CLI! 43 | * If you’re curious, there’s a README [here](https://github.com/facebook/react/blob/73f24269493bad75b64e8417675c1d76f6007ef0/scripts/release-manager/Readme.md). 44 | 45 | ------------ 46 | 47 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/24). 48 | -------------------------------------------------------------------------------- /2016-07/july-28.md: -------------------------------------------------------------------------------- 1 | ## July 28 ([discuss](https://github.com/reactjs/core-notes/pull/25)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 9 | * [Kevin](https://twitter.com/lacker) (Developer Advocacy) 10 | * [Paul](https://twitter.com/zpao) (React) 11 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 12 | * [Tom](https://twitter.com/tomocchino) (React) 13 | 14 | ### Individual Updates 15 | 16 | #### Ben 17 | 18 | * Ran the [`createClass` codemod](https://github.com/reactjs/react-codemod#class) on the Facebook.com codebase. 19 | * ES6 class usage is up from 30% to 80% in it! 20 | * More good news: [Public Class Fields](https://github.com/tc39/proposal-class-public-fields) (aka “Class Properties”) ES proposal has [advanced to Stage 2](https://github.com/tc39/proposals). 21 | 22 | #### Paul 23 | 24 | * Continued work on the [React release manager](https://github.com/reactjs/core-notes/blob/master/2016-07/july-21.md#react-release-manager). 25 | * Busy reviewing two pull requests: one from [Keyan](https://twitter.com/keyanzhang) and one from [Sebastian](https://twitter.com/sebmarkbage). 26 | * [Keyan](https://twitter.com/keyanzhang)’s pull request [changes React build process to use Rollup](https://github.com/facebook/react/pull/7178). 27 | * [Sebastian](https://twitter.com/sebmarkbage)’s pull request [significantly changes how React packages are bundled internally](https://github.com/facebook/react/pull/7168). 28 | * Unfortunately those changes conflict, and we are going with [Sebastian](https://twitter.com/sebmarkbage)’s pull request first. 29 | * See the section below explaining these changes in more detail. 30 | 31 | #### Dan 32 | 33 | * Released [Create React App](https://github.com/facebookincubator/create-react-app). 34 | * Lots of positive feedback. 35 | * Working on 0.2.0 that fixes issues with cloud editors and busy ports. 36 | * Missing features for calling it 1.0: testing, [proxying API requests](https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#proxying-api-requests-in-development). 37 | * We merged [Jest support](https://github.com/facebookincubator/create-react-app/pull/250) but people are concerned because it lost a ton of community trust in the first year. 38 | * We want to use Jest because we’re excited about [Snapshot Testing](https://facebook.github.io/jest/blog/2016/07/27/jest-14.html) and are committed to improving Jest. 39 | * [Dan](https://twitter.com/dan_abramov) will make sure the testing experience is good before releasing it officially. 40 | 41 | #### Kevin 42 | 43 | * React never had people working on developer advocacy and community outreach. 44 | * We feel it is time to improve this, and [Kevin](https://twitter.com/lacker) will help us. 45 | * He already worked on [revamping React Native docs](https://facebook.github.io/react-native/docs/getting-started.html) which was highly successful. 46 | * Things that need addressing: React docs, GitHub issue management. 47 | 48 | ### Changes to Bundling 49 | 50 | * Sebastian prepared a series of PRs that *really* split `react` and `react-dom` packages. ([#7164](https://github.com/facebook/react/pull/7164), [#7168](https://github.com/facebook/react/pull/7168), [#7173](https://github.com/facebook/react/pull/7173)) 51 | * `react-dom` package implementation used to live inside of `react` package for legacy reasons. 52 | * Now they are separated: `react` only contains “renderer-agnostic” things like `React.Component`, `React.createElement`, and `React.Children`. 53 | * This is still work in progress, and there are many weird hacks we have to do, but we’ll reduce them over time. 54 | 55 | #### Plan for Reconcilers and Renderers 56 | 57 | * Paradoxically, `react` package won’t include the React algorithm (“reconciler”) anymore. 58 | * For example, `React.createElement()` and `React.Component` stay there, but not the reconciler itself. 59 | * This makes sense because components relying on `react` don’t actually care how reconciler is implemented. 60 | * The React reconciler will exist in renderer packages such as `react-dom` and `react-native`. 61 | * Since almost nobody uses two renderers at the same time, each renderer will use a *copy* of the reconciler code. 62 | * This makes it possible for `react-native` and `react-dom` to move at different speeds and temporarily “fork” the reconciler code if needed. 63 | * This also makes it possible for `react-dom` to offer the new experimental [“Fiber” reconciler](https://github.com/reactjs/core-notes/blob/master/2016-06/june-23.md#update-on-fiber) behind a flag without changing all the third-party components that depend on `react`. 64 | * This sounds confusing but we think it’ll work better in practice. 65 | 66 | ------------ 67 | 68 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/25). 69 | -------------------------------------------------------------------------------- /2016-08/august-04.md: -------------------------------------------------------------------------------- 1 | ## August 4 ([discuss](https://github.com/reactjs/core-notes/pull/26)) 2 | 3 | ### Attendees 4 | 5 | * [Ben](https://twitter.com/soprano) (React) 6 | * [Christopher](https://twitter.com/vjeux) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Keyan](https://twitter.com/keyanzhang) (React, intern) 9 | * [Kevin](https://twitter.com/lacker) (Developer Advocacy) 10 | * [Paul](https://twitter.com/zpao) (React) 11 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 12 | * [Tom](https://twitter.com/tomocchino) (React) 13 | 14 | ### Individual Updates 15 | 16 | #### Ben 17 | 18 | * Participated in [React Application Architecture](https://twitter.com/soprano/status/759177157755019264) panel at [ForwardJS](https://forwardjs.com). 19 | * Reviewing [Keyan](https://twitter.com/keyanzhang)’s pull request that adds a UI for displaying warnings with “snooze”. ([#7360](https://github.com/facebook/react/pull/7360)) 20 | * Also reviewing [Sebastian](https://twitter.com/sebmarkbage)’s [pull requests](https://github.com/facebook/react/pulls?q=is%3Apr+author%3Asebmarkbage+fiber+is%3Aclosed) for the new [“Fiber” reconciler](https://github.com/reactjs/core-notes/blob/master/2016-06/june-23.md#update-on-fiber). 21 | 22 | #### Dan 23 | 24 | * Shipped more updates to [Create React App](https://github.com/facebookincubator/create-react-app). 25 | * There was more discussion about including Jest in the community. 26 | * [Christoph](https://twitter.com/cpojer) is working super hard to [turn Jest perception around](https://github.com/facebookincubator/create-react-app/pull/250#issuecomment-237098619) and make it a good test runner. 27 | * [Dan](https://twitter.com/dan_abramov) still has some concerns about Jest usability and will communicate them to [Christoph](https://twitter.com/cpojer) so they get fixed before Create React App officially includes testing. 28 | 29 | #### Keyan 30 | 31 | * Working on the new UI for warnings. ([#7360](https://github.com/facebook/react/pull/7360)) 32 | * Fixed an issue with inputs in mobile browsers. ([#7397](https://github.com/facebook/react/pull/7397)) 33 | * Also fixed a memory leak in server rendering in development. ([#7410](https://github.com/facebook/react/pull/7410)) 34 | 35 | #### Paul 36 | 37 | * Shipped [React 15.3.0](https://github.com/facebook/react/releases/tag/v15.3.0). 38 | * Working on internal codemods that remove code directly `import`ing modules from React on Facebook.com. 39 | * Switched the documentation to use [npmcdn](https://npmcdn.com/#/). ([#7394](https://github.com/facebook/react/pull/7394)) 40 | 41 | ------------ 42 | 43 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/26). 44 | -------------------------------------------------------------------------------- /2016-08/august-25.md: -------------------------------------------------------------------------------- 1 | ## August 25 ([discuss](https://github.com/reactjs/core-notes/pull/28)) 2 | 3 | ### Attendees 4 | 5 | We had no meeting because of [React Rally](http://reactrally.com) but we have some individual updates. 6 | 7 | ### Individual Updates 8 | 9 | #### Ben 10 | 11 | * Fixed DOM nesting message to be less confusing for whitespace. ([#7515](https://github.com/facebook/react/pull/7515)) 12 | * Currently at [React Rally](http://reactrally.com). 13 | 14 | #### Chris 15 | 16 | * Started adding Flow types to React codebase! ([PRs keep coming](https://github.com/facebook/react/pulls?utf8=%E2%9C%93&q=is%3Apr%20author%3Avjeux%20is%3Aclosed%20flow%20)) 17 | 18 | #### Dan 19 | 20 | * Spent a couple of weeks improving performance of React in development. (out in [15.3.1](https://github.com/facebook/react/releases/tag/v15.3.1)) 21 | * Fixed some issues in React DevTools and learned to release them. ([#409](https://github.com/facebook/react-devtools/pull/409), [#410](https://github.com/facebook/react-devtools/pull/410), [#411](https://github.com/facebook/react-devtools/pull/411), [#412](https://github.com/facebook/react-devtools/pull/412), [#413](https://github.com/facebook/react-devtools/pull/413)) 22 | * Released a few updates to Create React App ([0.2.2](https://github.com/facebookincubator/create-react-app/releases/tag/v0.2.2), [0.2.3](https://github.com/facebookincubator/create-react-app/releases/tag/v0.2.3)) 23 | * Fixed an annoying warning I previously introduced ([#7548](https://github.com/facebook/react/pull/7548)) 24 | * Added Chrome Timeline integration to ReactPerf ([#7549](https://github.com/facebook/react/pull/7549), scheduled for 15.4.0) 25 | * Going on a vacation from September 4th to September 20th. 26 | 27 | #### Paul 28 | 29 | * Shipped [React 15.3.1](https://github.com/facebook/react/releases/tag/v15.3.1). 30 | * Gave a talk about building React from scratch. [Check it out!](https://youtu.be/nI0cQ-2YR1I?t=1h7m15s) 31 | 32 | #### Sebastian 33 | 34 | * Looking into some race conditions in [Fiber](https://github.com/reactjs/core-notes/blob/master/2016-06/june-23.md#update-on-fiber). 35 | 36 | -------------------------------------------------------------------------------- /2016-10/october-13.md: -------------------------------------------------------------------------------- 1 | ## October 13 ([discuss](https://github.com/reactjs/core-notes/pull/33)) 2 | 3 | ### Attendees 4 | 5 | * [Dan](https://twitter.com/dan_abramov) (React) 6 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 7 | * [Tom](https://twitter.com/tomocchino) (React) 8 | 9 | ### Team Changes 10 | 11 | * [Jim](https://github.com/jimfb) has left Facebook to pursue other projects. Thanks to Jim for all his hard work and contributions! 12 | * [Paul](https://twitter.com/zpao) has left the React team to work on open source infrastructure at Facebook. Thanks to Paul for all the thankless work triaging issues and managing the release process! 13 | * [Christopher](https://twitter.com/vjeux) has switched to working on developer experience in Nuclide. Thanks to Christopher for his work on the React team (including inspiring and starting Create React App)! 14 | * [Andrew](http://twitter.com/acdlite) is going through the Bootcamp and will join the React team soon. 15 | 16 | The React core team now consists of: 17 | 18 | * [Andrew](https://twitter.com/acdlite) 19 | * [Ben](https://twitter.com/soprano) 20 | * [Dan](https://twitter.com/dan_abramov) 21 | * [Sebastian](https://twitter.com/sebmarkbage) 22 | * [Tom](https://twitter.com/tomocchino) (manager) 23 | 24 | ### Discussion 25 | 26 | #### Next Focus: Shipping Fiber 27 | 28 | We are shifting our focus and will spend the rest of the year working on [Fiber](https://github.com/facebook/react/issues/6170). This means we won't be working on JavaScript styles as originally planned. It seems like Fiber is our best shot at fixing many long-standing issues with React, and we are going to place all our effort into either replacing existing reconciler with Fiber, or failing spectacularly with it (and learning from that). 29 | 30 | #### New React Docs 31 | 32 | * Dan published [Codebase Overview](https://facebook.github.io/react/contributing/codebase-overview.html) and [Implementation Notes](https://facebook.github.io/react/contributing/implementation-notes.html) as he planned for a long time. 33 | * Andrew, Ben, Dan, [Héctor](https://github.com/hramos), [Eric](https://twitter.com/ericnakagawa), and [Kevin](http://twitter.com/lacker) are working on the new documentation for the React website ([#7864](https://github.com/facebook/react/pull/7864)). We rewrote all of the introductory content to use modern APIs and consistent terminology, and also rewrote some of the advanced content. Ben wrote a new tutorial that we've been using internally at Facebook for a while. Kevin drives this effort, will land next week. 34 | 35 | #### Releasing 15.4.0 36 | 37 | * Sebastian separated `React` from `ReactDOM` in [#7164](https://github.com/facebook/react/pull/7164) and this will get into 15.4.0. 38 | * This means that projects reaching into `react/lib/*` (which was never supported!) will break. 39 | * We published an RC and ask people to try it and file issues with breaking projects. ([#7770](https://github.com/facebook/react/issues/7770#issuecomment-253899837)) 40 | 41 | ------------ 42 | 43 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/33). 44 | -------------------------------------------------------------------------------- /2016-10/october-20.md: -------------------------------------------------------------------------------- 1 | ## October 20 ([discuss](https://github.com/reactjs/core-notes/pull/34)) 2 | 3 | ### Attendees 4 | 5 | * [Andrew](https://twitter.com/acdlite) (React) 6 | * [Ben](https://twitter.com/soprano) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 9 | * [Tom](https://twitter.com/tomocchino) (React) 10 | 11 | ### Individual Updates 12 | 13 | #### Andrew 14 | 15 | * Finishing Facebook Bootcamp and finally ready to join the team! 16 | 17 | #### Ben 18 | 19 | * Helping [Tim](https://twitter.com/yungsters) get React 15.4.0 (not published yet) into React Native. 20 | * This will be the first release where [React Native ships with its own copy of React, and `react` package won't include the reconciler](https://github.com/reactjs/core-notes/blob/master/2016-07/july-28.md#changes-to-bundling). 21 | 22 | #### Dan 23 | 24 | * Built a visual debugger to better understand how Fiber works. ([#8033](https://github.com/facebook/react/pull/8033)) 25 | * Not clear if this is useful, but it helped Dan better understand what's going on, and may help future contributors. 26 | 27 | #### Sebastian 28 | 29 | * Working on `setState` and lifycle hooks in Fiber. ([#8015](https://github.com/facebook/react/pull/8015)) 30 | * Documented some principles important for contributing to Fiber. ([#7942](https://github.com/facebook/react/issues/7942)) 31 | 32 | #### Discussions 33 | 34 | ##### New Lifecycle Sequences in Fiber 35 | 36 | Since Fiber supports interrrupting an update and resuming it later, there are some funny new lifecycle sequences. 37 | 38 | * For example, `componentWillMount()` may fire, but then the update might get deprioritized. Later the component might receive different props but we can't call `componentWillReceiveProps()` yet because the component has not mounted. Therefore, we will throw away the existing instance, create a new one with the new props, and call `componentWillMount()` on it. This will likely introduce memory leaks in components that subscribe to something in `componentWillMount()`, but this is already how React works on the server, so at least it's consistent. 39 | * Another fun consequence is that `componentWillUpdate()` and `componentWillReceiveProps()` may be called multiple times before the update is finally flushed and `componentDidUpdate()` is called. Each of those times `componentWillUpdate()`, `componentWillReceiveProps()`, and `shouldComponentUpdate()` will receive intermediate pending props which have not yet been flushed as `prevProps` and `nextProps`. However, `prevProps` in `componentDidUpdate()` will correspond to the last flushed props, so they might be older than the `prevProps` you got in `componentWillUpdate()`! All of this makes sense in isolation but may seem surprising. 40 | * To sum it up, if your components don't do anything too funny in lifecycles, they should work fine in Fiber. Fiber does its best to match the current semantics of lifecycle methods even when that leads to strange consequences. However some components relying on exact lifecycle order might break with Fiber. This is fine, as it's going to be a major release and likely opt-in at first. Eventually we'll probably want to redesign lifecycle methods to be more declarative and more aware of the specific use cases (e.g. subscriptions, data fetching, DOM manipulation, etc). 41 | 42 | #### Web Components, Properties and Attributes 43 | 44 | * There is a good discussion about enabling event support for Web Components. ([#7901](https://github.com/facebook/react/issues/7901)) 45 | * It seems like the tides are shifting towards using properties over attributes, as properties are richer. 46 | * We have an opportunity to make Web Components work better with React by adopting a "best practice" convention like the one [described here](https://github.com/webcomponents/react-integration). 47 | * [Rob Dodson](https://github.com/robdodson) of Polymer helps drive the discussion. 48 | 49 | #### Fiber Milestones 50 | 51 | * We need an actionable plan for developing and shipping Fiber. 52 | * We restructured an umbrella task for Fiber into "phases". ([#7925](https://github.com/facebook/react/issues/7925)) 53 | 54 | ------------ 55 | 56 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/34). 57 | -------------------------------------------------------------------------------- /2016-10/october-27.md: -------------------------------------------------------------------------------- 1 | ## October 27 ([discuss](https://github.com/reactjs/core-notes/pull/35)) 2 | 3 | ### Attendees 4 | 5 | * [Andrew](https://twitter.com/acdlite) (React) 6 | * [Ben](https://twitter.com/soprano) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 9 | * [Tom](https://twitter.com/tomocchino) (React) 10 | 11 | ### Individual Updates 12 | 13 | #### Andrew 14 | 15 | * Implemented string refs on top of callback refs in Fiber. ([#8099](https://github.com/facebook/react/pull/8099)) 16 | * Implemented support for `PureComponent` to Fiber. ([#8118](https://github.com/facebook/react/pull/8118)) 17 | * Working on making `ReactDOM.render()` synchronous by default in Fiber, and adding support for `unstable_batchedUpdates()` to Fiber. ([#8127](https://github.com/facebook/react/pull/8127)) 18 | * Will work again on something like [#7457](https://github.com/facebook/react/pull/7457) so that `setState()` inside low priority trees does not cause them to get a high priority. 19 | 20 | #### Ben 21 | 22 | * We are already [tracking](https://github.com/facebook/react/blob/facts/fiber-tests.txt) how many tests as passing on Fiber. Working on setting up infrastructure so we know which tests exactly are failing, and make sure we don't regress on old tests as we add new features. 23 | 24 | #### Dan 25 | 26 | * Merged [Jim](https://github.com/jimfb)'s pull request for making error boundaries work for updates in the existing reconciler, and added more tests. They are still hidden behind an `unstable_` API prefix as they are not fully supported. ([#7949](https://github.com/facebook/react/pull/7949)) 27 | * Working on supporting error boundaries in Fiber. It already implements more cases than error boundaries in the existing reconciler. ([#8095](https://github.com/facebook/react/pull/8095)) 28 | 29 | #### Sebastian 30 | 31 | * Fixed a few bugs in Fiber and implemented `findDOMNode()` and `isMounted()`. ([#8083](https://github.com/facebook/react/pull/8083)) 32 | * Working on adding DOM attributes and events to Fiber. 33 | * Working with [Christopher](https://twitter.com/vjeux) on getting [#8117](https://github.com/facebook/react/pull/8117) merged. Chistopher needs it for Nuclide. 34 | 35 | #### Tom 36 | 37 | * Made a website to track our progress working on Fiber: [isfiberreadyyet.com](http://isfiberreadyyet.com/). 38 | 39 | ### Discussions 40 | 41 | #### Release Process 42 | 43 | * [Paul](https://twitter.com/zpao) has left the team and will work on open source tooling at Facebook. Somebody needs to take over the release process. Ben agreed to help with 15.4.0. 44 | * Paul was working on a [release manager](https://github.com/facebook/react/pull/7330) so releasing is more automated. However nobody used it yet. We'll probably need some help from Paul to demo it to us when he's back from a vacation. 45 | 46 | 47 | ------------ 48 | 49 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/35). 50 | -------------------------------------------------------------------------------- /2016-11/november-03.md: -------------------------------------------------------------------------------- 1 | ## November 3 ([discuss](https://github.com/reactjs/core-notes/pull/36)) 2 | 3 | ### Attendees 4 | 5 | * [Andrew](https://twitter.com/acdlite) (React) 6 | * [Ben](https://twitter.com/soprano) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Paul](https://twitter.com/zpao) (Open Source Tools) 9 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 10 | * [Tom](https://twitter.com/tomocchino) (React) 11 | 12 | ### Individual Updates 13 | 14 | #### Andrew 15 | 16 | * Working on batching updates. `setState` is normally asynchronous in Fiber but it should be synchronous inside `componentDidMount` and `componentDidUpdate`. Also implementing opt-in `ReactDOM.unstable_batchedUpdates` for feature parity. ([#8193](https://github.com/facebook/react/pull/8193)) 17 | * It turned out to be significantly easier in Fiber to call `setState` callbacks right after `componentDidUpdate` rather than at the very end of all updates. We’re going to change the existing reconciler to match this behavior in React 16. (Ben will make the change in [#8204](https://github.com/facebook/react/pull/8204)) 18 | 19 | #### Ben 20 | 21 | * Wrote a script that keeps track of which tests [fail](https://github.com/facebook/react/blob/master/scripts/fiber/tests-failing.txt) and [pass](https://github.com/facebook/react/blob/master/scripts/fiber/tests-passing.txt) in Fiber. 22 | * New PRs now need to run `scripts/fiber/record-tests` so that we can catch unexpected Fiber regressions. 23 | * Working on infrastructure to ignore tests that just check for warnings, as they’re less important while we work on Fiber feature parity. 24 | 25 | #### Dan 26 | 27 | * Fixed a few issues in Fiber scheduler. ([#8172](https://github.com/facebook/react/pull/8172), [#8187](https://github.com/facebook/react/pull/8187)) 28 | * Collaborating with Andrew on error boundaries and batching in Fiber. ([#8193](https://github.com/facebook/react/pull/8193), [#8210](https://github.com/facebook/react/pull/8210)) 29 | 30 | #### Paul 31 | 32 | * Visiting from Seattle to meet with his new team, stopped by to attend the meeting. 33 | * Gave us an overview of new Facebook open source pipeline: [facebookexperimental](https://github.com/facebookexperimental) → [facebookincubator](https://github.com/facebookincubator) → [facebook](https://github.com/facebook). 34 | * At his new team, Paul will work to encourage more open source projects at Facebook. 35 | 36 | #### Sebastian 37 | 38 | * Working on a major refactoring of the event system. ([#8176](https://github.com/facebook/react/pull/8176), [#8190](https://github.com/facebook/react/pull/8190), [#8192](https://github.com/facebook/react/pull/8192), [#8229](https://github.com/facebook/react/pull/8229)) 39 | * The goal is to change it to attach event listeners at the root of the tree instead of the document. ([#8117](https://github.com/facebook/react/pull/8117)) 40 | * The next step is integrating the event system into Fiber. 41 | 42 | ### Discussions 43 | 44 | #### Shipping 15.4.0 45 | 46 | * React Native integration has been rocky because it now ships with its own copy of the reconciler, but we’re close. 47 | 48 | #### Fiber Milestones 49 | 50 | * We added an internal opt-in flag for employees to render Facebook.com with Fiber. Everything is broken right now but we can now focus on getting simple components working. 51 | 52 | ------------ 53 | 54 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/36). 55 | -------------------------------------------------------------------------------- /2016-11/november-10.md: -------------------------------------------------------------------------------- 1 | ## November 10 ([discuss](https://github.com/reactjs/core-notes/pull/37)) 2 | 3 | ### Attendees 4 | 5 | * [Andrew](https://twitter.com/acdlite) (React) 6 | * [Ben](https://twitter.com/soprano) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 9 | * [Tom](https://twitter.com/tomocchino) (React) 10 | 11 | ### Individual Updates 12 | 13 | #### Andrew 14 | 15 | * Figuring out what the right behavior for error boundaries and uncaught errors should be in Fiber. For now, decided that we're going to unmount the whole tree when there is an uncaught error. We can potentially keep the DOM tree in the future. ([#8227](https://github.com/facebook/react/pull/8227)) 16 | 17 | #### Ben 18 | 19 | * Working on infrastructure that lets us separate dev-only test failures (such as warning assertions) from real failures. This will help us focus on bugs in Fiber. Such assertions will be using `expectDev()` instead of `expect()`. ([#8228](https://github.com/facebook/react/pull/8228)) 20 | 21 | #### Dan 22 | 23 | * Fixed a few minor issues in Fiber related to `TestUtils`. 24 | 25 | #### Sebastian 26 | 27 | * Working on integrating DOM properties and events into Fiber. 28 | 29 | ### Why So Little? 30 | 31 | We’re focused on [getting Fiber ready](http://isfiberreadyyet.com/) and have [many remaining issues](https://github.com/facebook/react/issues/7925) to work on so we don’t talk as much. :-) 32 | 33 | ------------ 34 | 35 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/37). 36 | -------------------------------------------------------------------------------- /2016-12/december-01.md: -------------------------------------------------------------------------------- 1 | ## December 1 ([discuss](https://github.com/reactjs/core-notes/pull/38)) 2 | 3 | ### Attendees 4 | 5 | * [Andrew](https://twitter.com/acdlite) (React) 6 | * [Ben](https://twitter.com/soprano) (React) 7 | * [Dan](https://twitter.com/dan_abramov) (React) 8 | * [Tom](https://twitter.com/tomocchino) (React) 9 | 10 | ### Individual Updates 11 | 12 | #### Andrew 13 | 14 | * Finished a very long PR with new error boundary semantics for Fiber. If there is an error, the error boundary renders `null` first. After reconciliation is complete, the error boundary gets an `unstable_handleError(error)` call and has a chance to `setState()` there to render the error message. If there are no boundaries and the error is unhandled, the whole tree gets unmounted (which prevents data corruption via broken UI). We might consider keeping the UI in some form in the future (for example, with `visibility: hidden`) but for now unmounting is easier. The next step will be to get rid of nested `try` / `catch`es in the scheduler to avoid performance issues. ([#8304](https://github.com/facebook/react/pull/8304)) 15 | 16 | #### Ben 17 | 18 | * Switched Facebook to use Fiber by default **for the React team**. It kinda works! **Nobody else sees it in production** but we can start dogfooding it and [add FB-specific issues to the umbrella task](https://github.com/facebook/react/issues/7925) so that we can fix them before dogfooding Fiber in other teams. 🎉 19 | 20 | #### Dan 21 | 22 | * Added `ReactDOM.unstable_createPortal(domNode)` to replace `ReactDOM.unstable_renderContainerToSubtree()` in Fiber. The old API isn’t going away yet but will be phased out after Fiber is released. ([#8386](https://github.com/facebook/react/pull/8386)) 23 | * Added support for iterables (e.g. Immutable lists) to Fiber and refactored existing tests to test the public API instead of internal helpers. ([#8446](https://github.com/facebook/react/pull/8446)) 24 | * Added some tests for error boundaries and uncaught errors to prevent regressions. ([#8462](https://github.com/facebook/react/pull/8462)) 25 | * Working on adding support for SVG to Fiber. ([#8417](https://github.com/facebook/react/pull/8417), [#8475](https://github.com/facebook/react/pull/8475)) 26 | 27 | #### Sebastian 28 | 29 | * Currently at the TC39 meeting. 30 | 31 | ### Fiber Kinda Works 32 | 33 | This is fully rendered with [Fiber](https://github.com/acdlite/react-fiber-architecture): 34 | 35 | ![Fiber recording](https://d17oy1vhnax1f7.cloudfront.net/items/0m262R3W3Q3k0o2I1T24/Screen%20Recording%202016-12-01%20at%2008.20%20pm.gif?v=cce24841) 36 | 37 | **Note: Only the React team members are currently opted into using Fiber at Facebook. We need to dogfood it for a while and find most bugs before we can start officially integrating it into the products. Only then can we start thinking about an official release, as [many things are still missing](https://github.com/facebook/react/issues/7925).** 38 | 39 | 40 | ------------ 41 | 42 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/38). 43 | -------------------------------------------------------------------------------- /2016-12/december-08.md: -------------------------------------------------------------------------------- 1 | ## December 8 ([discuss](https://github.com/reactjs/core-notes/pull/39)) 2 | 3 | This meeting is special for three reasons! 4 | 5 | * [Brian](https://twitter.com/brian_d_vaughn) of [React Virtualized](https://bvaughn.github.io/react-virtualized/) fame **has joined the team!** 🎉 6 | * [IsFiberReadyYet.com](http://isfiberreadyyet.com/) is now **rendered with Fiber**. 7 | * We are sharing **our goals and areas of focus for the first half of 2017** (read below!) 8 | 9 | ### Attendees 10 | 11 | * [Adam Wolff](https://twitter.com/dmwlff) (Front End Infrastructure) 12 | * [Andrew](https://twitter.com/acdlite) (React) 13 | * [Ben](https://twitter.com/soprano) (React) 14 | * [Brian](https://twitter.com/brian_d_vaughn) (React) 15 | * [Dan](https://twitter.com/dan_abramov) (React) 16 | * [Sebastian](https://twitter.com/sebmarkbage) (React) 17 | * [Tom](https://twitter.com/tomocchino) (React) 18 | 19 | ### Invididual Updates 20 | 21 | #### Andrew 22 | 23 | * Landed a big restructuring of Fiber scheduler that avoids excessive `try` / `catch`es. ([#8479](https://github.com/facebook/react/pull/8479)) 24 | * Will keep working on improving Fiber scheduler. ([#8538](https://github.com/facebook/react/pull/8538)) 25 | 26 | #### Ben 27 | 28 | * Keeping track of Fiber bugs we found testing Fiber at Facebook. ([#7925](https://github.com/facebook/react/issues/7925)) 29 | 30 | #### Brian 31 | 32 | * Ported [React ART](https://github.com/reactjs/react-art) to Fiber using the new renderer API. ([#8521](https://github.com/facebook/react/pull/8521)) 33 | 34 | #### Dan 35 | 36 | * Been bikeshedding on how to implement SVG with Sebastian for a while. ([#8417](https://github.com/facebook/react/pull/8417), [#8475](https://github.com/facebook/react/pull/8475)) 37 | * Settled on the approach and landed an imperfect version of SVG support to iterate later. ([#8490](https://github.com/facebook/react/pull/8490)) 38 | 39 | #### Sebastian 40 | 41 | * Fixing different bugs in Fiber. 42 | 43 | #### Tom 44 | 45 | * Now that we have SVG, ported [IsFiberReadyYet.com](http://isfiberreadyyet.com/) to use Fiber. 46 | 47 | ---------------------- 48 | 49 | ## Plan for the First Half of 2017 50 | 51 | ### Goals 52 | 53 | * Deliver on the promise of Fiber 54 | * Understand and improve byte-size and runtime performance 55 | 56 | ### Prerequisite work 57 | 58 | See the [Fiber umbrella issue](https://github.com/facebook/react/issues/7925) for a more detailed list of remaining work on the new version of the React core (aka “Fiber”), which will replace the old version (aka “Stack”) in 2017. In summary: 59 | 60 | * Do performance testing on Facebook products 61 | * Implement developer facing warnings 62 | * Fix remaining bugs and failing unit tests 63 | * Implement the React Native Fiber renderer 64 | * Figure out what to do about server-side rendering 65 | 66 | Note that while Fiber is a complete rewrite of React, it strives to maintain backwards compatibility wherever possible. We are already testing existing products on it with little to no changes to their code. 67 | 68 | ### Start to deliver on the promise of Fiber 69 | 70 | In addition to being a complete rewrite to the React core that we hope will be smaller and faster, Fiber gives us the ability to fix long standing issues and add long requested features: 71 | 72 | * Return multiple components from render (aka fragments) 73 | * Return text from render 74 | * Proper and comprehensive support for error boundaries 75 | * New API for portals that unifies scheduling of different subtrees 76 | * Much, much easier to write custom renderers for React (web, native, canvas, GL, etc) 77 | 78 | We will release the above along with the rollout of Fiber in early 2017, and will then shift our focus toward other projects which will help to realize some of the future promise of our investment: 79 | 80 | ### Understand and improve byte-size and runtime performance 81 | 82 | Fiber allows us to make more sophisticated scheduling decisions to improve perceived performance and user experience. To reduce UI stalls and jank, we can make two changes to how React functions: 83 | 84 | * Change default rendering mode to async so high-priority user interactions can interrupt other low-priority rendering work 85 | * Expose developer accessible hooks to allow more sophisticated control of rendering priorities 86 | 87 | We’ve seen an increasing number of libraries inspired by React that promise to be faster and smaller than React. This half we will do an investigation into byte-size and initialization time and use that knowledge to improve React's start-up time. We will also investigate more sophisticated compilation techniques. 88 | 89 | ### Additional work and stretch goals 90 | 91 | After releasing Fiber broadly, we will begin work to remove the old React core, which will require that we have complete feature parity with the existing React core. This will require that we: 92 | 93 | * Implement React DevTools support in Fiber 94 | * Figure out and communicate subtle timing differences between Stack and Fiber 95 | * Move the shallow and test renderers off of the old Stack reconciler 96 | * Create a plan to support server-side rendering with Fiber 97 | 98 | In addition to the above we may also focus on these important areas as stretch goals: 99 | 100 | * Design new functional component API with declarative data subscriptions 101 | * Publicly deprecate `createClass` 102 | * Clean up old addons and cyclic dependencies 103 | * Make release process more straightforward 104 | * Make implementation safer with Flow 105 | 106 | ------------ 107 | 108 | Please feel free to discuss these notes in the [corresponding pull request](https://github.com/reactjs/core-notes/pull/39). 109 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # React Core Meeting Notes 2 | 3 | React Core team meets once a week to discuss the development of React, future plans, and priorities. 4 | These notes are relatively new and started in March, 2016. You can find an archive of older notes [here](https://discuss.reactjs.org/c/meeting-notes). 5 | 6 | New notes will be added as pull requests so you will be notified of them if you watch the repo. 7 | You can comment on the pull requests to discuss the notes, or raise issues if you would like to ask for a clarification. 8 | 9 | The repo format is inspired by [Ember Core Notes](https://github.com/emberjs/core-notes). 10 | 11 | ## Recent Notes 12 | 13 | #### December 14 | 15 | * [December 8](https://github.com/reactjs/core-notes/blob/master/2016-12/december-08.md) ([discuss](https://github.com/reactjs/core-notes/pull/39)) 16 | * [December 1](https://github.com/reactjs/core-notes/blob/master/2016-12/december-01.md) ([discuss](https://github.com/reactjs/core-notes/pull/38)) 17 | 18 | #### November 19 | 20 | * November 24 (no meeting) 21 | * November 17 (no meeting but we [released React 15.4.0](https://facebook.github.io/react/blog/2016/11/16/react-v15.4.0.html)!) 22 | * [November 10](https://github.com/reactjs/core-notes/blob/master/2016-11/november-10.md) ([discuss](https://github.com/reactjs/core-notes/pull/37)) 23 | * [November 3](https://github.com/reactjs/core-notes/blob/master/2016-11/november-03.md) ([discuss](https://github.com/reactjs/core-notes/pull/36)) 24 | 25 | #### October 26 | 27 | * [October 27](https://github.com/reactjs/core-notes/blob/master/2016-10/october-27.md) ([discuss](https://github.com/reactjs/core-notes/pull/35)) 28 | * [October 20](https://github.com/reactjs/core-notes/blob/master/2016-10/october-20.md) ([discuss](https://github.com/reactjs/core-notes/pull/34)) 29 | * [October 13](https://github.com/reactjs/core-notes/blob/master/2016-10/october-13.md) ([discuss](https://github.com/reactjs/core-notes/pull/33)) 30 | * October 6 (no meeting) 31 | 32 | #### September 33 | 34 | * No regular meetings ([what happened?](https://github.com/reactjs/core-notes/issues/31#issuecomment-255113577)) 35 | 36 | #### August 37 | 38 | * [August 25](https://github.com/reactjs/core-notes/blob/master/2016-08/august-25.md) ([discuss](https://github.com/reactjs/core-notes/pull/28)) 39 | * August 18 (no meeting) 40 | * August 11 (no meeting) 41 | * [August 4](https://github.com/reactjs/core-notes/blob/master/2016-08/august-04.md) ([discuss](https://github.com/reactjs/core-notes/pull/26)) 42 | 43 | #### July 44 | 45 | * [July 28](https://github.com/reactjs/core-notes/blob/master/2016-07/july-28.md) ([discuss](https://github.com/reactjs/core-notes/pull/25)) 46 | * [July 21](https://github.com/reactjs/core-notes/blob/master/2016-07/july-21.md) ([discuss](https://github.com/reactjs/core-notes/pull/24)) 47 | * July 14 (no meeting) 48 | * [July 7](https://github.com/reactjs/core-notes/blob/master/2016-07/july-07.md) ([discuss](https://github.com/reactjs/core-notes/pull/23)) 49 | 50 | #### June 51 | 52 | * [June 30](https://github.com/reactjs/core-notes/blob/master/2016-06/june-30.md) ([discuss](https://github.com/reactjs/core-notes/pull/22)) 53 | * [June 23](https://github.com/reactjs/core-notes/blob/master/2016-06/june-23.md) ([discuss](https://github.com/reactjs/core-notes/pull/21)) 54 | * June 16 (no meeting) 55 | * [June 9](https://github.com/reactjs/core-notes/blob/master/2016-06/june-09.md) ([discuss](https://github.com/reactjs/core-notes/pull/19)) 56 | * [June 2](https://github.com/reactjs/core-notes/blob/master/2016-06/june-02.md) ([discuss](https://github.com/reactjs/core-notes/pull/18)) 57 | 58 | #### May 59 | 60 | * [May 26](https://github.com/reactjs/core-notes/blob/master/2016-05/may-26.md) ([discuss](https://github.com/reactjs/core-notes/pull/17)) 61 | * [May 19](https://github.com/reactjs/core-notes/blob/master/2016-05/may-19.md) ([discuss](https://github.com/reactjs/core-notes/pull/15)) 62 | * [May 12](https://github.com/reactjs/core-notes/blob/master/2016-05/may-12.md) ([discuss](https://github.com/reactjs/core-notes/pull/14)) 63 | * [May 5](https://github.com/reactjs/core-notes/blob/master/2016-05/may-05.md) ([discuss](https://github.com/reactjs/core-notes/pull/13)) 64 | 65 | #### April 66 | 67 | * [April 28](https://github.com/reactjs/core-notes/blob/master/2016-04/april-28.md) ([discuss](https://github.com/reactjs/core-notes/pull/10)) 68 | * [April 21](https://github.com/reactjs/core-notes/blob/master/2016-04/april-21.md) ([discuss](https://github.com/reactjs/core-notes/pull/8)) 69 | * April 14 (no meeting) 70 | * [April 7](https://github.com/reactjs/core-notes/blob/master/2016-04/april-07.md) ([discuss](https://github.com/reactjs/core-notes/pull/3)) 71 | 72 | #### March 73 | 74 | * [March 31](https://github.com/reactjs/core-notes/blob/master/2016-03/march-31.md) ([discuss](https://github.com/reactjs/core-notes/pull/1)) 75 | 76 | ## Archive 77 | 78 | You can find an archive of older notes [here](https://discuss.reactjs.org/c/meeting-notes). 79 | --------------------------------------------------------------------------------