-
Notifications
You must be signed in to change notification settings - Fork 2.7k
[Draft] Release notes #12852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Draft] Release notes #12852
Conversation
Removes puffery and adds some context for readers
* Add React Compiler section * Clarify some existing parts of release-notes.md
|
commit: |
size-limit report 📦
|
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 26 new, 66 changed, 5 removedBuild ID: 6dc0572e2d09117b5d69a740 URL: https://www.apollographql.com/docs/deploy-preview/6dc0572e2d09117b5d69a740 |
jerelmiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bignimbus I'll review this more in depth after I get through the migration guide, but posted a couple quick thoughts after skimming through.
apollo-client-4-blog-post.md
Outdated
|
|
||
| ## Dramatically Smaller Bundles | ||
|
|
||
| Bundle size has been a top concern in community feedback, and we've taken it seriously. Apollo Client 4.0 introduces opt-in architecture for features that not everyone needs. The most impactful change is making local state management opt-in. If you're not using `@client` directives for local state, you no longer carry that code in your bundle. When you do need it, importing `LocalState` from `@apollo/client/local-state` gives you the same powerful local state management you're used to, but only when you actually use it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LocalState is a big one, but there are a few others that also got this treatment that impact bundle size because the implementation can be tree-shaken away (HttpLink is another example, it is no longer bundled with ApolloClient if you're using a different termininating link). Does it make sense to focus just on local state here, or should we make it a more general statement? That said, local state is the biggest contributor to this pattern 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made an edit to allow for more nuance here, does that seem closer to what we're looking for?
|
|
||
| We've also modernized our build targets. Apollo Client 4.0 ships JavaScript transpiled for browsers from 2023 and Node.js 20+, taking advantage of native language features instead of polyfills. Combined with proper ESM support and improved tree-shaking, most applications will see a **20-30%** reduction in Apollo Client's bundle size contribution. For teams fighting to stay under performance budgets, this improvement alone makes upgrading worthwhile. | ||
|
|
||
| ## TypeScript That Helps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A BIG part of the TypeScript story in 4.0 is the enforcement of required variables, the addition of type overrides, and defining context types for the link chain. I think we should try and mention these as well. Now that we have the TypeScript guide merged, check out the new doc for more information:
- Working with variables: https://www.apollographql.com/docs/deploy-preview/24caa435c923afea6779941a/react/data/typescript#working-with-variables
- Type overrides: https://www.apollographql.com/docs/deploy-preview/24caa435c923afea6779941a/react/data/typescript#overriding-type-implementations-for-built-in-types
- Context types: https://www.apollographql.com/docs/deploy-preview/24caa435c923afea6779941a/react/data/typescript#defining-context-types
I would definitely leave what you have in here since it is the other big piece of the TypeScript story, but if we can find a way to mention these as well, that would be awesome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed an update that elaborates on the TS story - lmk what you think!
Co-authored-by: Lenz Weber-Tronic <[email protected]>
Co-authored-by: Lenz Weber-Tronic <[email protected]>
Opening this PR to allow for comments. We'll close this once we are happy with the content and port it over to the blog.