blog: Table v9 type perf blog#979
Merged
Merged
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
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)
📝 WalkthroughWalkthroughThis PR adds a new blog post documenting the TypeScript type-checking performance improvements made to TanStack Table V9 from alpha.54 through beta.12, 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
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 256: Fix the spelling error in the opening sentence of the paragraph that
starts with "The large improvment came from noticing that internal code doesn't
need the feature-conditional view at all." Change the misspelled word
"improvment" to "improvement" to correct the grammar.
- Line 4: The performance range claim of "66-86% across every package and
example" in the excerpt (line 4) and opening line (line 14) is inaccurate based
on the measured data shown below in the document. The core and adapter tables
show improvements from -62.1% to -85.9%, while kitchen-sink examples range from
36% to 79%, making the actual spread 36-86% across all packages and examples.
Update both line 4 and line 14 to either widen the range to 36-86% to cover all
examples, split the claim with separate ranges for core/adapters versus
examples, or remove the specific percentage range entirely and direct readers to
the detailed tables below for the complete performance breakdown.
🪄 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: 149c4eb6-da39-4074-8ca7-a8d9fb336de4
📒 Files selected for processing (1)
src/blog/tanstack-table-v9-typescript-performance.md
AlemTuzlak
approved these changes
Jun 15, 2026
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
3 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