|
| 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). |
0 commit comments