- Ben (React)
- Christopher (React)
- Dan (React)
- Keyan (React, intern)
- Paul (React)
- Sebastian (React)
- Tom (React)
- We don’t currently allow returning multiple elements from
- This has been a long requested feature in the community.
- We generally agree that it should be implemented but we found it to be hard with our existing architecture.
- There exists a fork that implements fragments but we don’t want to take this implementation.
- It introduces them only for React DOM which would make React features inconsistent across renderers.
- It also introduces some complexity we would like to avoid because we might start breaking other things with it.
- Fiber supports fragments but it’s far from done.
- We will include work on fragments in our plan for the second half of 2016.
- Since we want this feature anyway, we can implement it in existing reconciler independently of Fiber.
- We think that React provides good value for its build size (~45kB min+gzip).
- However we understand everybody has different constraints, especially with small apps.
- We intend to be more mindful of the build size to avoid accidental regressions.
- Keyan is investigating using Rollup for our UMD builds. (#7178)
- After #7178 is merged, the minified post-gzip size will reduce by 14%. (46kB → 39kB)
- For now, we will use a hack to transpile CommonJS to ES Modules so Rollup understands them.
- Longer term, we’d like to use ES Modules in the source but Facebook internal bundlers don’t understand them yet.
- Dan asked why the event system is so large.
- It accounts for a noticeable chunk of React build size.
- Looking at other “React-like” libraries, no one has an event system like ours. Why?
Why We Need It
- The intention was to normalize events with weird behavior like
- This lets component authors not worry about inconsistencies with bubbling and input events, making ecosystem better.
- The React Native gesture handling system is also built around it.
- The browsers have improved, so we will keep re-evaluating it once in a while, but for now we find it useful.
What We Can Improve
- It is overabstracted, and we can simplify code by baking support for some “plugins” right into it.
- There is some code duplication we can reduce in the event whitelist.
- Some weird patterns like
keyOf()exist to be compatible with GCC. Perhaps we could find another way to fix this?
Please feel free to discuss these notes in the corresponding pull request.