fix: recs update fix type #436
Conversation
WalkthroughAll references to the Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant Client
participant LocalState
Caller->>Client: getEntities / getEventMessages
Client-->>Caller: Response with models[]
Caller->>LocalState: Insert models into DB / set models in state
Caller->>Caller: Check models.length for pagination
Possibly related PRs
Poem
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. ✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (3)
packages/state/src/recs/index.ts (3)
225-236: 🛠️ Refactor suggestionType cast to
anyshould be improved with a proper type definition.Similar to the earlier instance, using
anytype for the response fromgetEventMessagesbypasses TypeScript's type checking system. Consider defining a proper interface for the response structure.-const entities = (await client.getEventMessages({ +interface ToriiResponse { + models: Record<string, any>; + next_cursor: string; +} + +const entities = (await client.getEventMessages({ pagination: { limit, cursor, direction: "Forward", order_by: orderBy, }, clause: clause || undefined, no_hashed_keys: false, models: entityModels, historical, -})) as any; +})) as ToriiResponse;🧰 Tools
🪛 Biome (1.9.4)
[error] 236-236: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
285-296: 🛠️ Refactor suggestionType cast to
anyshould be improved with a proper type definition.Using
anybypasses TypeScript's type safety. Consider using the same interface type suggested earlier for all Torii client responses.If you implement the
ToriiResponseinterface suggested earlier, you can use it here as well:-const fetchedEntities = (await client.getEntities({ +const fetchedEntities = (await client.getEntities({ pagination: { limit, cursor, direction: "Forward", order_by: orderBy, }, clause: entityKeyClause, no_hashed_keys: false, models: entityModels, historical, -})) as any; +})) as ToriiResponse;🧰 Tools
🪛 Biome (1.9.4)
[error] 296-296: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
164-175: 💡 Verification agent🧩 Analysis chain
Type cast to
anyshould be improved with a proper type definition.The change from
itemstomodelsin the response structure is good, but usinganytype bypasses TypeScript's type checking system, which could lead to potential runtime errors. Consider defining an interface for the response structure instead.
🏁 Script executed:
#!/bin/bash # Check if there's a type definition for the Torii client response grep -r "interface.*Response" --include="*.ts" . # Alternatively, check if there are any existing typings for models property grep -r "models:.*\[\]" --include="*.ts" .Length of output: 768
Define a proper response type instead of
anyYou should replace the
as anycast with a real TypeScript interface so you get full type-checking on the response. For example, inpackages/state/src/recs/index.ts(around lines 164–175):
Add a response interface (e.g. in a new or existing
packages/state/src/types.ts):export interface GetEntitiesResponse<TModel> { items: TModel[]; // or `models: TModel[]` if the API really returns “models” pagination: { limit: number; cursor: string | null; direction: "Forward" | "Backward"; order_by: keyof TModel; }; no_hashed_keys: boolean; historical: boolean; }Update the call to use a generic:
// Old:
const entities = (await client.getEntities({
const entities = await client.getEntities<GetEntitiesResponse<MyEntityModel>>({ pagination: { … }, clause: clause || undefined, no_hashed_keys: false, models: entityModels, historical, });
- Replace
MyEntityModelwith the actual model interface you’re querying.This way you avoid
any, get proper type safety on the API response, and catch potential mismatches at compile time.🧰 Tools
🪛 Biome (1.9.4)
[error] 175-175: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
🧹 Nitpick comments (2)
packages/state/src/recs/index.ts (2)
181-181: Template literal can be simplified.While the property update from
itemstomodelsis good, the template literal is unnecessary when no interpolation is needed in the first part of the string.-if (logging) console.log(`Fetched entities`, entities.models); +if (logging) console.log("Fetched entities", entities.models);🧰 Tools
🪛 Biome (1.9.4)
[error] 181-181: Do not use template literals if interpolation and special-character handling are not needed.
Unsafe fix: Replace with string literal
(lint/style/noUnusedTemplateLiteral)
164-306: Overall assessment of type property change fromitemstomodels.The PR correctly updates all references from
itemstomodelsproperty in the Torii client responses, which aligns with the API changes. However, I recommend defining proper interface types instead of usinganytype assertions to maintain type safety.Consider creating a shared type definition file for Torii client responses to ensure consistency across the codebase and improve type safety. This would eliminate the need for
anytype assertions and provide better IntelliSense support and compile-time checks.🧰 Tools
🪛 Biome (1.9.4)
[error] 175-175: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
[error] 181-181: Do not use template literals if interpolation and special-character handling are not needed.
Unsafe fix: Replace with string literal
(lint/style/noUnusedTemplateLiteral)
[error] 212-212: This default parameter should follow the last required parameter or should be a required parameter.
The last required parameter is here:
A default parameter that precedes a required parameter cannot be omitted at call site.
Unsafe fix: Turn the parameter into a required parameter.(lint/style/useDefaultParameterLast)
[error] 213-213: This default parameter should follow the last required parameter or should be a required parameter.
The last required parameter is here:
A default parameter that precedes a required parameter cannot be omitted at call site.
Unsafe fix: Turn the parameter into a required parameter.(lint/style/useDefaultParameterLast)
[error] 214-214: This default parameter should follow the last required parameter or should be a required parameter.
The last required parameter is here:
A default parameter that precedes a required parameter cannot be omitted at call site.
Unsafe fix: Turn the parameter into a required parameter.(lint/style/useDefaultParameterLast)
[error] 214-214: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 216-216: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 217-217: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 236-236: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
[error] 249-249: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
[error] 277-277: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 278-278: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 279-279: This type annotation is trivially inferred from its initialization.
Safe fix: Remove the type annotation.
(lint/style/noInferrableTypes)
[error] 296-296: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
examples/example-vite-svelte-recs/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
packages/state/src/recs/index.ts(6 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
packages/state/src/recs/index.ts
[error] 175-175: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
[error] 181-181: Do not use template literals if interpolation and special-character handling are not needed.
Unsafe fix: Replace with string literal
(lint/style/noUnusedTemplateLiteral)
[error] 236-236: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
[error] 296-296: Unexpected any. Specify a different type.
any disables many type checking rules. Its use should be avoided.
(lint/suspicious/noExplicitAny)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: check
- GitHub Check: build
🔇 Additional comments (4)
packages/state/src/recs/index.ts (4)
178-178: Consistent property update fromitemstomodels.Good update to reflect the new API response structure.
183-183: Consistent property updates fromitemstomodels.These updates correctly align with the new API response structure.
Also applies to: 185-185
238-242: Consistent property updates fromitemstomodels.These updates correctly adapt to the new API response structure.
301-301: Consistent property updates fromitemstomodels.These updates correctly align with the new API response structure.
Also applies to: 304-304, 306-306
Summary by CodeRabbit