Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe changes refactor RPC and OpenAPI link classes across multiple adapters. The Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant R as RPCLink
participant SR as StandardRPCLink
participant LC as LinkClient
C->>R: Invoke RPC call
R->>SR: Delegate request
SR->>LC: Process with options
LC-->>SR: Return result
SR-->>R: Pass response
R-->>C: Return result
sequenceDiagram
participant C as Client
participant OH as OpenAPIHandler
participant SOH as StandardOpenAPIHandler
participant RT as Router
C->>OH: Send request (/ping?input=hello)
OH->>SOH: Forward request
SOH->>RT: Route & process request
RT-->>SOH: Return dynamic output
SOH-->>OH: Deliver processed response
OH-->>C: Return final response
Possibly related PRs
Poem
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (2)
✨ Finishing Touches
🪧 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 (
|
More templates
@orpc/arktype
@orpc/client
@orpc/contract
@orpc/openapi-client
@orpc/react
@orpc/react-query
@orpc/openapi
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/svelte-query
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
![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
🧹 Nitpick comments (1)
packages/client/src/adapters/standard/rpc-link.ts (1)
11-19: Good abstraction with StandardRPCLink.The new
StandardRPCLinkclass properly encapsulates the common RPC link initialization logic. This refactoring helps eliminate redundant code that was previously duplicated across different link implementations.However, consider adding JSDoc documentation to explain the purpose of this class and its parameters for better developer experience.
+/** + * A standard implementation of an RPC link that handles serialization and encoding of RPC requests. + */ export class StandardRPCLink<T extends ClientContext> extends StandardLink<T> { + /** + * Creates a new StandardRPCLink instance. + * @param linkClient - The client that handles the underlying network requests + * @param options - Configuration options for the RPC link + */ constructor(linkClient: StandardLinkClient<T>, options: StandardRPCLinkOptions<T>) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
packages/client/src/adapters/fetch/rpc-link.ts(1 hunks)packages/client/src/adapters/standard/rpc-link.test.ts(1 hunks)packages/client/src/adapters/standard/rpc-link.ts(1 hunks)packages/openapi-client/src/adapters/fetch/openapi-link.ts(1 hunks)packages/openapi-client/src/adapters/standard/openapi-link.test.ts(1 hunks)packages/openapi-client/src/adapters/standard/openapi-link.ts(1 hunks)packages/openapi/src/adapters/fetch/openapi-handler.test.ts(1 hunks)packages/openapi/src/adapters/fetch/openapi-handler.ts(1 hunks)packages/openapi/src/adapters/node/openapi-handler.test.ts(1 hunks)packages/openapi/src/adapters/standard/openapi-handler.test.ts(1 hunks)packages/openapi/src/adapters/standard/openapi-handler.ts(1 hunks)packages/server/src/adapters/fetch/rpc-handler.test.ts(1 hunks)packages/server/src/adapters/node/rpc-handler.test.ts(1 hunks)
🔇 Additional comments (31)
packages/server/src/adapters/node/rpc-handler.test.ts (3)
8-8: Handler now processes dynamic inputThe handler has been updated to use a more flexible pattern where it takes input and returns it as part of the output object, replacing the previous static response pattern.
14-14: Test updated to include dynamic test dataThe test now sends an encoded JSON object with a "json":"value" pair, reflecting the shift to dynamic input processing.
16-16: Test expectation updated to match new output patternThe expectation now checks for the dynamic value from the input rather than a static string, which properly validates the new handler behavior.
packages/openapi/src/adapters/fetch/openapi-handler.test.ts (3)
6-6: Route handling updated to support path and dynamic inputThe handler now defines a specific path ('/ping') and processes input dynamically, consistent with the standardization efforts in this PR.
8-8: Test updated to provide input via query parameterThe test now sends a request with a query parameter ('input=hello') that will be processed by the handler, testing the dynamic input handling capability.
12-12: Test assertion updated to check dynamic responseThe test now verifies that the response contains the input value ('hello') instead of a static string, properly validating the new dynamic behavior.
packages/openapi/src/adapters/standard/openapi-handler.test.ts (3)
1-8: New test suite for StandardOpenAPIHandlerThis test appropriately establishes the test environment for the new StandardOpenAPIHandler class, using a similar route definition pattern as seen in the other refactored tests.
9-20: Test case for GET request handlingThe test correctly validates the handler's ability to process GET requests with query parameters, providing a thorough test of the request handling flow including URL parsing and context management.
21-23: Assertion validates structured response formatThe test properly verifies that the handler returns a structured response object containing the input value, demonstrating the standardized response format.
packages/server/src/adapters/fetch/rpc-handler.test.ts (3)
6-6: Handler updated to support dynamic input processingThe handler implementation now processes input and returns it as part of the output object, consistent with the pattern used in other adapter tests.
10-10: Test updated with encoded JSON inputThe test now sends an encoded JSON object with test data, providing a proper test case for the dynamic input handling capability.
14-14: Test assertion updated to verify dynamic responseThe expectation now correctly checks for the presence of the dynamic input value in the response, validating the end-to-end functionality of the handler.
packages/openapi/src/adapters/node/openapi-handler.test.ts (3)
8-8: Good update to handle dynamic inputThe handler now processes input from the request and returns it in the response, which is more realistic and better tests the actual behavior of the handler in production use.
11-12: Good test for prefix functionalityTesting the handler with a prefix option ensures that path prefixing works correctly in production scenarios where API endpoints might be mounted under a specific path.
14-14: Proper assertion for dynamic responseThe expectation now correctly validates that the input value is present in the response, aligning with the handler implementation that returns the input.
packages/client/src/adapters/fetch/rpc-link.ts (2)
4-4: Good refactoring to extend StandardRPCLinkExtending the new
StandardRPCLinkclass instead ofStandardLinkcreates a more specific inheritance hierarchy and better separates concerns. This follows the principle of composition over inheritance and helps with code organization.Also applies to: 10-10
14-14: Simplified constructor with better encapsulationThe constructor is now simpler and delegates the creation of serializers and codecs to the parent class. This improves encapsulation and reduces duplication of code across different implementations.
packages/openapi/src/adapters/fetch/openapi-handler.ts (1)
5-5: Good refactoring to use StandardOpenAPIHandlerUsing the new
StandardOpenAPIHandlerclass simplifies the implementation by delegating the creation of serializers and codecs to a specialized class. This reduces code duplication and improves maintainability by centralizing the OpenAPI handling logic.Also applies to: 9-9
packages/client/src/adapters/standard/rpc-link.test.ts (5)
7-9: Good test setup with proper cleanupUsing
beforeEachto clear mocks ensures that each test runs with a clean state, which helps prevent test interdependencies and flaky tests.
11-12: Comprehensive test structure with parameterizationUsing
describe.eachto test multiple data types and HTTP methods is an excellent approach that ensures thorough coverage while keeping the test code DRY. This will make it easier to add new data types or methods in the future.
13-44: Well-structured success case test helperThe
assertSuccessCasefunction is well-designed with:
- Clear mocking of dependencies
- Proper setup of the
StandardRPCHandlerandStandardRPCLink- Appropriate expectations to verify both the output and the handler invocation
This ensures thorough testing of the success path.
46-83: Thorough error case testingThe
assertErrorCasefunction properly tests error handling by:
- Throwing a specific
ORPCErrorwith test data- Verifying that the error is properly propagated through the link
- Checking that the error properties are preserved
This ensures robust error handling in the RPC link.
85-88: Comprehensive test cases for various data structuresThe tests cover multiple scenarios:
- Flat values
- Nested objects
- Complex objects with special characters and collections (lists, maps, sets)
This thorough testing approach ensures that the RPC link correctly handles a wide range of data types and structures, which is crucial for a robust RPC implementation.
Also applies to: 90-93, 95-131
packages/openapi-client/src/adapters/fetch/openapi-link.ts (1)
4-4: Nice refactoring to use StandardOpenAPILink!The refactoring simplifies this class by extending
StandardOpenAPILinkinstead of implementing the serialization logic directly. This reduces code duplication and centralizes the OpenAPI link implementation.Also applies to: 9-9, 13-13
packages/openapi-client/src/adapters/standard/openapi-link.ts (1)
2-8: Good implementation of StandardOpenAPILinkThis new standard class is well-structured and extracts the common OpenAPI link logic from adapter-specific implementations. It handles the creation of serializers and the codec, which was previously duplicated across different adapters.
Also applies to: 12-20
packages/openapi/src/adapters/standard/openapi-handler.ts (1)
1-20: Good implementation of StandardOpenAPIHandlerThis follows the same refactoring pattern as the link classes. Creating a standard handler implementation reduces duplication and provides a consistent pattern across the codebase.
packages/openapi-client/src/adapters/standard/openapi-link.test.ts (4)
6-35: Good test setup with mock router and handlerThe test setup is clear and well-structured. It creates a test router with GET and POST handlers, and correctly configures the StandardOpenAPILink with a mock call implementation.
36-54: Good test coverage for GET methodThis test effectively validates that the GET method correctly processes input parameters, including nested objects and date values.
56-101: Comprehensive test coverage for POST method with different input typesThese tests thoroughly validate the POST method with various input scenarios, including regular JSON data, Blob objects in nested structures, and Blob objects at the root level. This ensures the StandardOpenAPILink handles all these cases correctly.
24-28: Good error handlingThe error handling in the mock call implementation is simple but effective, ensuring that the tests will fail clearly if no response is received.
packages/client/src/adapters/standard/rpc-link.ts (1)
2-6: Import statements are correctly updated for the new structure.The changes appropriately import the necessary types and classes that will be used in the new
StandardRPCLinkclass, including theStandardRPCSerializerwhich is a new dependency.
1 participant
Summary by CodeRabbit