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