feat(endpoint): allow shared Collection context keys#3931
Conversation
Allow one Collection schema to provide both argsKey and nestKey so it can be reused top-level and nested while preserving shared collection state. Made-with: Cursor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: ea20542 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Size Change: +19 B (+0.02%) Total Size: 81.1 kB 📦 View Changed
ℹ️ View Unchanged
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3931 +/- ##
==========================================
- Coverage 98.21% 98.20% -0.01%
==========================================
Files 154 154
Lines 3018 3013 -5
Branches 604 601 -3
==========================================
- Hits 2964 2959 -5
Misses 11 11
Partials 43 43 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Benchmark React
Details
| Benchmark suite | Current: ea20542 | Previous: 6e8e499 | Ratio |
|---|---|---|---|
data-client: getlist-100 |
140.85 ops/s (± 5.1%) |
129.87 ops/s (± 4.5%) |
0.92 |
data-client: getlist-500 |
42.11 ops/s (± 4.6%) |
39.6 ops/s (± 6.1%) |
0.94 |
data-client: update-entity |
370.37 ops/s (± 10.9%) |
303.03 ops/s (± 7.7%) |
0.82 |
data-client: update-user |
408.33 ops/s (± 8.7%) |
312.5 ops/s (± 7.9%) |
0.77 |
data-client: getlist-500-sorted |
42.39 ops/s (± 8.1%) |
42.02 ops/s (± 6.8%) |
0.99 |
data-client: update-entity-sorted |
307.77 ops/s (± 9.3%) |
250 ops/s (± 5.7%) |
0.81 |
data-client: update-entity-multi-view |
339.08 ops/s (± 9.7%) |
277.78 ops/s (± 7.0%) |
0.82 |
data-client: list-detail-switch-10 |
7.77 ops/s (± 8.2%) |
7.91 ops/s (± 8.9%) |
1.02 |
data-client: update-user-10000 |
75.19 ops/s (± 11.7%) |
71.18 ops/s (± 11.9%) |
0.95 |
data-client: invalidate-and-resolve |
37.18 ops/s (± 5.0%) |
34.42 ops/s (± 5.3%) |
0.93 |
data-client: unshift-item |
215.08 ops/s (± 5.2%) |
200 ops/s (± 5.3%) |
0.93 |
data-client: delete-item |
285.71 ops/s (± 5.4%) |
263.16 ops/s (± 6.0%) |
0.92 |
data-client: move-item |
177.01 ops/s (± 8.9%) |
165.3 ops/s (± 9.5%) |
0.93 |
This comment was automatically generated by workflow using github-action-benchmark.
There was a problem hiding this comment.
Benchmark
Details
| Benchmark suite | Current: ea20542 | Previous: 6e8e499 | Ratio |
|---|---|---|---|
normalizeLong |
439 ops/sec (±3.83%) |
425 ops/sec (±3.99%) |
0.97 |
normalizeLong Values |
403 ops/sec (±0.23%) |
401 ops/sec (±0.76%) |
1.00 |
normalizeLong Scalar |
343 ops/sec (±0.45%) |
325 ops/sec (±1.31%) |
0.95 |
normalizeLong Scalar update |
842 ops/sec (±1.50%) |
852 ops/sec (±0.51%) |
1.01 |
denormalizeLong |
245 ops/sec (±4.43%) |
245 ops/sec (±4.39%) |
1 |
denormalizeLong Values |
223 ops/sec (±3.70%) |
225 ops/sec (±3.43%) |
1.01 |
denormalizeLong donotcache |
1029 ops/sec (±0.11%) |
948 ops/sec (±0.21%) |
0.92 |
denormalizeLong Values donotcache |
752 ops/sec (±0.37%) |
718 ops/sec (±0.21%) |
0.95 |
denormalizeLong Scalar donotcache |
1012 ops/sec (±0.15%) |
904 ops/sec (±0.18%) |
0.89 |
denormalizeShort donotcache 500x |
1491 ops/sec (±0.10%) |
1522 ops/sec (±0.10%) |
1.02 |
denormalizeShort 500x |
680 ops/sec (±3.32%) |
708 ops/sec (±4.09%) |
1.04 |
denormalizeShort 500x withCache |
7379 ops/sec (±0.05%) |
6485 ops/sec (±0.19%) |
0.88 |
queryShort 500x withCache |
3050 ops/sec (±0.07%) |
2848 ops/sec (±0.11%) |
0.93 |
buildQueryKey All |
48837 ops/sec (±0.51%) |
52373 ops/sec (±0.48%) |
1.07 |
query All withCache |
6589 ops/sec (±0.67%) |
6822 ops/sec (±0.26%) |
1.04 |
denormalizeLong with mixin Entity |
240 ops/sec (±4.09%) |
233 ops/sec (±4.38%) |
0.97 |
denormalizeLong withCache |
7009 ops/sec (±0.14%) |
7112 ops/sec (±0.32%) |
1.01 |
denormalizeLong withCache (Scalar churn) |
6951 ops/sec (±0.14%) |
6957 ops/sec (±0.27%) |
1.00 |
denormalizeLong Values withCache |
6686 ops/sec (±0.31%) |
5237 ops/sec (±0.17%) |
0.78 |
denormalizeLong Scalar withCache |
7476 ops/sec (±1.13%) |
7958 ops/sec (±1.00%) |
1.06 |
denormalizeLong Scalar update withCache |
5538 ops/sec (±0.52%) |
4113 ops/sec (±0.28%) |
0.74 |
denormalizeLong All withCache |
6146 ops/sec (±0.15%) |
6497 ops/sec (±0.32%) |
1.06 |
denormalizeLong Query-sorted withCache |
6667 ops/sec (±0.17%) |
6832 ops/sec (±0.22%) |
1.02 |
denormalizeLongAndShort withEntityCacheOnly |
1598 ops/sec (±0.18%) |
1743 ops/sec (±0.25%) |
1.09 |
denormalize bidirectional 50 |
4824 ops/sec (±5.11%) |
4984 ops/sec (±4.68%) |
1.03 |
denormalize bidirectional 50 donotcache |
44041 ops/sec (±0.29%) |
39469 ops/sec (±0.18%) |
0.90 |
getResponse |
5626 ops/sec (±1.48%) |
4732 ops/sec (±0.94%) |
0.84 |
getResponse (null) |
10361268 ops/sec (±0.46%) |
9991985 ops/sec (±0.90%) |
0.96 |
getResponse (clear cache) |
230 ops/sec (±4.20%) |
230 ops/sec (±3.63%) |
1 |
getSmallResponse |
3791 ops/sec (±0.91%) |
3485 ops/sec (±0.38%) |
0.92 |
getSmallInferredResponse |
2770 ops/sec (±0.18%) |
2699 ops/sec (±0.13%) |
0.97 |
getResponse Collection |
5564 ops/sec (±1.52%) |
4675 ops/sec (±0.72%) |
0.84 |
get Collection |
5282 ops/sec (±0.39%) |
4702 ops/sec (±0.32%) |
0.89 |
get Query-sorted |
6615 ops/sec (±0.34%) |
5280 ops/sec (±0.33%) |
0.80 |
setLong |
447 ops/sec (±0.09%) |
442 ops/sec (±0.12%) |
0.99 |
setLongWithMerge |
250 ops/sec (±0.22%) |
252 ops/sec (±0.30%) |
1.01 |
setLongWithSimpleMerge |
269 ops/sec (±0.19%) |
269 ops/sec (±0.25%) |
1 |
setSmallResponse 500x |
915 ops/sec (±0.09%) |
943 ops/sec (±0.08%) |
1.03 |
This comment was automatically generated by workflow using github-action-benchmark.
Motivation
Collections often need the same logical key both as a top-level endpoint schema and as a nested Entity field. Previously this required two separate
Collectioninstances: one withargsKeyand one withnestKey.Solution
Allow one
Collectionto define bothargsKeyandnestKey, using endpoint args at the top level and nested parent context inside Entities. This updates endpoint types, tests, docs, v0.17 migration guidance, playground editor types, and adds a changeset.Open questions
N/A
Made with Cursor
Note
Medium Risk
Changes how
Collection.pk()is computed depending on whether normalization is nested under an Entity, which can affect cache keying and queryKey behavior across existing apps. Broad surface-area updates (types, docs, tests, playground d.ts) reduce risk but require careful verification of normalization/denormalization consistency.Overview
Enables a single
Collectioninstance to be reused both as a top-level endpoint schema and as a nestedEntityfield by supporting bothargsKeyandnestKey, and routingpk()tonestKeyonly when normalized under an Entity (parentEntityprovided) otherwise usingargsKey.Updates
Collectionconstruction defaults (always has anargsKeyfallback), extendsCollection.pk()/normalize()type signatures to acceptparentEntity, and adjustsqueryKey()behavior accordingly; adds/updates tests to cover shared nested/top-level collections and push propagation.Refreshes docs/migration guidance/blog + playground
.d.tsto reflect the new combined-key pattern, and includes minor type tweaks in generated editor typings (e.g.WeakDependencyMap.set()signature anduuid.parse()return type alias).Reviewed by Cursor Bugbot for commit ea20542. Bugbot is set up for automated code reviews on this repo. Configure here.