-
Notifications
You must be signed in to change notification settings - Fork 52
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
fix: typedoc ci #365
fix: typedoc ci #365
Conversation
WalkthroughThe pull request introduces changes across three files, focusing on enhancing code modularity and test robustness. In the Vite kitchen sink example, new calldata builder functions are added to the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
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.
Actionable comments posted: 0
🧹 Nitpick comments (4)
examples/example-vite-kitchen-sink/src/typescript/contracts.gen.ts (1)
59-65
: Parameter-based calldata builder is well-implemented.This function correctly handles the
value: CairoCustomEnum
parameter. Consider adding a short doc comment describing valid enum values and expected usage if needed.packages/sdk/src/__example__/index.ts (3)
123-123
: Minor labeling discrepancy.The console error text says "Error querying todos and goals," but the code references a query for "player" data. Consider adjusting the message for clarity.
- console.error("Error querying todos and goals:", resp.error.message); + console.error("Error querying player data:", resp.error.message);
130-131
: Log message mismatch with actual data.The same "todos and goals" text is retained in the success log, which might cause confusion if it differs from the real query target. Consider updating the log statement accordingly.
- console.log("Queried todos and goals:", resp.data.map((a) => a.models.world)); + console.log("Queried player data:", resp.data.map((a) => a.models.world));
145-161
: Similar mismatch in log messages within callback.The error and success messages reference "completed important todos," but the code is querying items and games. Consider aligning the log text to match the actual query target.
- console.error("Error querying completed important todos:", resp.error.message); + console.error("Error querying items and games:", resp.error.message); - console.log("Completed important todos:", resp.data.map((a) => a.models)); + console.log("Queried items and games:", resp.data.map((a) => a.models));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
examples/example-vite-kitchen-sink/src/typescript/contracts.gen.ts
(1 hunks)packages/sdk/src/__example__/index.ts
(1 hunks)packages/sdk/src/__tests__/parseEntities.test.ts
(3 hunks)
🔇 Additional comments (16)
examples/example-vite-kitchen-sink/src/typescript/contracts.gen.ts (11)
13-19
: Well-structured calldata builder function.This function neatly encapsulates the calldata for incrementing the global counter. It's consistent with the overall approach of separating data construction and execution logic. No issues here.
27-27
: Great use of the new builder function.The invocation cleanly references the builder function, promoting consistency and reducing duplication.
32-32
: Error handling is appropriate.Logging the error and re-throwing it ensures that upstream code can handle the exception or log additional details as needed.
36-42
: Builder function mirrors the first one—solid consistency.The same pattern used to build calldata for incrementing the caller counter maintains clarity and uniformity in the codebase.
50-50
: Good usage of the second builder function.Keeping the invocation straightforward with the builder function fosters reliability and uniform usage across the code.
55-55
: Error handling remains consistent.Similar to the previous function, the error is logged and re-thrown, allowing higher-level functions to manage the exception.
74-74
: Appropriately references the theme calldata builder.Maintains the modular design by reusing the dedicated builder function. Good job!
79-79
: Consistent error handling approach.Re-throwing after logging ensures that calling functions can distinguish or recover from the error if needed.
86-87
: Calldata builder included in the return object matches the naming convention.Exposing
buildIncrementGlobalCounterCalldata
aligns with the new pattern of returning builder references. Everything looks good.
89-90
: Similarly exposed builder function.
buildIncrementCallerCounterCalldata
is consistent with the structure of the incrementGlobalCounter builder. Good consistency!
92-92
: Calldata builder for theme changes is well-integrated.Including
buildChangeThemeCalldata
in the return object ensures a uniform strategy for all actions within thesetupWorld
function.packages/sdk/src/__example__/index.ts (2)
118-120
: Subscription refactor brings better structure.Encapsulating the query and callback via an object makes the subscription call more explicit, aiding readability. Keep it up!
138-144
: Query building addresses multiple entities.Filtering items and games in the same query is concise. The approach is logically sound.
packages/sdk/src/__tests__/parseEntities.test.ts (3)
225-225
: Optional chaining prevents potential runtime errors.Accessing
res[0]?.models?.onchain_dash?.CallerCounter?.timestamp
is a safe and robust approach, avoiding crashes if objects are undefined.
279-279
: Using optional chaining for complex enums is sound.This ensures no unhandled
undefined
from the parse results. Great job improving reliability.
336-336
: Same effective improvement with optional chaining.Again, preventing potential runtime errors if the parse result doesn't match expectations. Well done.
Summary by CodeRabbit