blog: Table v9 type perf blog#979
Open
KevinVandy wants to merge 6 commits into
Open
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThis PR adds a new blog post documenting the TypeScript type-checking performance improvements made to TanStack Table V9 from alpha.54 through beta.11, detailing the shift from conditional unions to feature maps, optimization techniques, measurement methodology, and practical guidance for developers. ChangesTypeScript Performance Optimization Blog Post
Estimated Code Review Effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested Reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/blog/tanstack-table-v9-typescript-performance.md`:
- Line 16: Fix the typo in the intro sentence: replace the phrase "turned our to
be one of our bigger optimizations" with "turned out to be one of our bigger
optimizations" so the sentence reads correctly.
- Around line 257-261: The paragraph overstates the safety of the `in out`
variance claim; replace the sentences that say "`in out` annotation is simply
trusted" and "sound to do regardless of the structure" with a more accurate
explanation: state that `in out` asserts invariance for the compiler's
instantiation-based comparisons and can bypass structural variance probing
(i.e., the compiler will use the annotated invariance rather than derive
variance from the type's structure), that this usually only restricts
assignability but can also remove relations the code relies on (as shown by
`TValue` breaking the build), and therefore it should be applied only where
parameters are invariant in practice (keeping the `Table_Internal` and `TValue`
examples as-is to illustrate the benefit and caveat).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0e6d1f5f-d5d0-48de-88f5-ab374867343d
⛔ Files ignored due to path filters (1)
public/blog-assets/tanstack-table-v9-typescript-performance/header.pngis excluded by!**/*.png
📒 Files selected for processing (1)
src/blog/tanstack-table-v9-typescript-performance.md
| --- | ||
| title: TypeScript Performance in TanStack Table V9 | ||
| published: 2026-06-13 | ||
| excerpt: TanStack Table V9's types do a lot more than V8's did. Here's how we cut type instantiations by 66-85% across every package between the alpha.54 and beta.11 to keep the editor experience feeling nearly instant. |
Contributor
There was a problem hiding this comment.
"nearly"? why so defensive?
Member
Author
There was a problem hiding this comment.
In my own experience, there's usually still a noticeable few tenths of a second for the type to pop up. Plus there is still a lot of things going on that make this a slower typescript experience compared to v8. It's just way less of a time cost now and the tradeoffs are worth it.
So I didn't think "nearly" was defensive, just accurate
|
|
||
|  | ||
|
|
||
| TanStack Table V9 has a much more capable, though more complex, type system than V8. The types in Table may not be as complicated as a project like TanStack Router or Form, but it has still grown more complex in V9 than it ever had been in previous versions. |
Contributor
There was a problem hiding this comment.
is "type system" the right term here?
Member
Author
There was a problem hiding this comment.
I want a better term. What should it be?
Contributor
There was a problem hiding this comment.
"type-level API" maybe?
|
|
||
| TanStack Table V9 has a much more capable, though more complex, type system than V8. The types in Table may not be as complicated as a project like TanStack Router or Form, but it has still grown more complex in V9 than it ever had been in previous versions. | ||
|
|
||
| If you had been using the Table V9 alphas, there's a chance that you could feel a bit of slowness in your editor. Good news, though! Between the alpha and the latest beta, we cut TypeScript's type-checking work by 66-85% across every package and example! The latest beta now type-checks faster than our alpha versions from last week by a wide margin, and the editor experience is back to feeling nearly instant. |
|
|
||
| If you had been using the Table V9 alphas, there's a chance that you could feel a bit of slowness in your editor. Good news, though! Between the alpha and the latest beta, we cut TypeScript's type-checking work by 66-85% across every package and example! The latest beta now type-checks faster than our alpha versions from last week by a wide margin, and the editor experience is back to feeling nearly instant. | ||
|
|
||
| This post covers where the cost came from, how we measured it, and the specific changes that fixed these issues. One of those changes is a still overlooked TypeScript feature that many library authors still seem to barely use, and it turned our to be one of our bigger optimizations, turning a trade-off into a win across the board. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/blog/tanstack-table-v9-typescript-performance.md`:
- Line 14: The headline at line 14 claims a 66-85% improvement "across every
package and example," but the measured data in the tables below shows results
ranging from as low as 36% for examples and 62.1% for `@tanstack/vue-table`, which
fall outside this range. Either widen the percentage range to accurately reflect
all measured improvements (likely 36-85% or similar), or narrow the claim by
removing "across every package and example" and specifying only which packages
or examples achieve the 66-85% improvement. Apply the same correction at line 4,
which contains the identical claim. Ensure the headline numbers align with the
complete data presented in the tables below.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9c7ef0bb-b78c-422a-a091-5418440fac15
📒 Files selected for processing (1)
src/blog/tanstack-table-v9-typescript-performance.md
|
|
||
| TanStack Table V9 has a much more capable, though more complex, type-level API than V8. The types in Table may not be as complicated as a project like TanStack Router or Form, but it has still grown more complex in V9 than it ever had been in previous versions. | ||
|
|
||
| If you had been using the Table V9 alphas, there's a chance that you could feel a bit of slowness in your editor. Good news, though! Between the alpha and the latest beta, we cut TypeScript's type-checking work by 66-85% across every package and example! The latest beta now type-checks faster than our alpha versions from last week by a wide margin, and the editor experience is back to feeling instant. |
There was a problem hiding this comment.
Align the headline numbers with the tables below.
The intro/excerpt say 66–85% "across every package and example," but the later results include @tanstack/vue-table at 62.1% and examples as low as 36%. Please narrow the claim or remove the single range so the summary matches the measured data.
🛠️ Suggested wording
- excerpt: TanStack Table V9's types do a lot more than V8's did. Here's how we cut type instantiations by 66-85% across every package between the alpha.54 and beta.11 to keep the editor experience feeling instant.
+ excerpt: TanStack Table V9's types do a lot more than V8's did. Here's how we cut type instantiations across packages and examples between the alpha.54 and beta.11 to keep the editor experience feeling instant.
- Between the alpha and the latest beta, we cut TypeScript's type-checking work by 66-85% across every package and example!
+ Between the alpha and the latest beta, we cut TypeScript's type-checking work across packages and examples, with the full spread shown in the tables below.Also applies to: 4-4
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/blog/tanstack-table-v9-typescript-performance.md` at line 14, The
headline at line 14 claims a 66-85% improvement "across every package and
example," but the measured data in the tables below shows results ranging from
as low as 36% for examples and 62.1% for `@tanstack/vue-table`, which fall outside
this range. Either widen the percentage range to accurately reflect all measured
improvements (likely 36-85% or similar), or narrow the claim by removing "across
every package and example" and specifying only which packages or examples
achieve the 66-85% improvement. Apply the same correction at line 4, which
contains the identical claim. Ensure the headline numbers align with the
complete data presented in the tables below.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit