May 12 (discuss)
- Alex (React Native)
- Ben (React)
- Christoph (Jest)
- Christopher (React Native)
- Dan (React)
- Jim (React)
- Paul (React)
- Sebastian (React)
- Shayne (React Native)
- Tom (React)
- Christopher is going on a parental leave and will continue his experiments in July.
- Don’t forget that this is tied to Facebook build asset pipeline, and is not directly applicable to React.
- However lessons learned from this work may influence our thinking about inline styles in the future.
- People have been complaining about the lack of error messages in production React.
- Many of them aren’t actionable anyway, but some can be useful.
- We might want to consider an error code system.
- Babel transform annotates every callsite with a number that’s known statically.
- Sentry (and others!) can look up that number in a map.
- A new intern will be working on this!
- Keyan will be working on the React team as an intern.
- Ben will be mentoring him.
- The plan is for him to work on the error code system described above.
- Another thing he might work on is a “yellow box” a la React Native.
- Where should it go? fbjs?
- Could be a more effective vector for communication between the React core team and users of React than console warnings.
- To be practical, we would need to have warning levels and some way of suppressing them.
- This is just an idea, the details would need to be fleshed out.
- A longstanding issue with a very long thread.
- Sebastian has been thinking about this (just this morning!)
- With the incremental reconciler, we think we’ll solve this.
- It will make things a lot more inefficient.
- Only some libraries use context for dynamically updating values, but enabling deep subscriptions by default will hurt performance for everyone.
- For now, React Router 3.0 adds a hacky workaround.
- @taion plans to pull it out in a generic module for other affected libraries.
- Nobody is really happy about it, but hopefully it should be easy to pull it out later.
- It uses mixins so it’s easier to pull it out, and it doesn’t trash React DevTools view.
- Hopefully eventually React fixes this, and React Router can
unpublishstop using that package.
- Long-term ideas and features often block incremental and external contributions.
- We might want to spend more time just supporting features the community is asking for, even if we don't use them.
- One concern is that the proposed solution often will leave us in a worse place than where we were before.
- This is often not obvious in the beginning, and unfortunately a lot of work may get done before we realize this.
- Maybe as a team we can focus on one area at a time.
- For example, let’s just do one thing, do it well, and ship it.
- Better than letting ourselves get overwhelmed.
- We can focus on external needs, but we also need to make sure that external folks are willing to support our needs internally.
- This requires that we better communicate our needs and priorities.
- There’s a long unwritten list of constraints, and we often reactively provide that list.
- But it’s hard for contributors to know before they work on their big PR what that list is.
- We should adopt an RFC process!
- Long discussions should start before folks submit a PR.
- In some cases, they can start after, but not in the PR itself.
- Let’s use the Rust / Ember RFC process.
- Cristian in London is working on snapshot testing in Jest.
- Ben has been prototyping a full React test renderer that can render everything both on React Native and DOM.
- Unlike shallow renderer, it is stateful and renders deeply.
- Things won’t actually render to React Native or to the DOM, but rather to an intermediate representation.
- This will give us the ability to diff representations.
- (Basically we’re pretty-printing JSX and then doing textual diffs.)
- It is not clear if the intermediate representation should include information about composite components (the “DevTools tree”).
- Maybe this could be configurable.
Please feel free to discuss these notes in the corresponding pull request.