You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.
This issue will serve as a place for discussing and coordinating bundle size improvements of any kind, including but not limited to the following techniques:
Reimplementing surprisingly heavy dependencies locally, a la 4bac03a.
Making it easier to import specific parts of the react-apollo package, by supporting multiple entry points, e.g. react-apollo/browser and react-apollo/server. Note: this may be less important if we can rely on effective tree-shaking and ESM bundling.
Transforming imports to be more specific using a compiler plugin, so that import { SpecificThing } from "react-apollo" becomes import { SpecificThing } from "react-apollo/lib/specific-thing". If we end up pursuing this approach for apollo-client, we will no doubt reuse the same tools here. Note: because this would impose new build-time requirements, we should wait to try this approach until it seems like the only/best option.
Somehow code-splitting the library, even though dynamic import() is not an option for libraries that must be consumed by bundlers with different runtime implementations of dynamic modules.
Introducing a production bundle in addition to the development bundle, with more aggressive elimination of unnecessary code (e.g. error strings).
Playing to the strengths of the advanced bundlers that our most bundle-size-conscious users are likely to be using.
Pull requests are more than welcome! Here's a list of PRs that have contributed (or promise to contribute) to reducing bundle sizes:
Part of #2743.
The current bundle size is about 9.9KB, so 10KB gives us a tiny bit of
breathing room. Any PRs that push the react-apollo bundle over 10KB
deserve a closer look to make sure they're as conservative as they can be
(within reason).
@benjamn one thing about the bundle size are the graphql queries. I understand that apollo uses some parts of the queries (e.g. default values). Is there a way to throw away part of the queries on the client side and replace the queries with a hash (similar to automated persisted queries)?
I guess this would help a lot in practice, what do you think?
Reducing bundle sizes is an on-going battle, and is something we keep in the fore front of our minds with every PR merged. All of the work associated with this issue has been merged, and we'll continue to work on bundle size reduction with every release. Thanks all!
In the same spirit as apollographql/apollo-client#4324, the bundle footprint of the
react-apollo
package (currently 32.7KB minified, 8.7KB after gzip) could be, well, smaller.This issue will serve as a place for discussing and coordinating bundle size improvements of any kind, including but not limited to the following techniques:
react-apollo
package, by supporting multiple entry points, e.g.react-apollo/browser
andreact-apollo/server
. Note: this may be less important if we can rely on effective tree-shaking and ESM bundling.import { SpecificThing } from "react-apollo"
becomesimport { SpecificThing } from "react-apollo/lib/specific-thing"
. If we end up pursuing this approach forapollo-client
, we will no doubt reuse the same tools here. Note: because this would impose new build-time requirements, we should wait to try this approach until it seems like the only/best option.import()
is not an option for libraries that must be consumed by bundlers with different runtime implementations of dynamic modules.Pull requests are more than welcome! Here's a list of PRs that have contributed (or promise to contribute) to reducing bundle sizes:
react-apollo@2.5.0
: [WIP] Reduce bundle size. #2661examples/rollup
: Bundle reductions inspired by examples/rollup app. #2842The text was updated successfully, but these errors were encountered: