refactor(client, server): reduce link and handler options#202
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe changes standardize dependency injection and initialization across various adapter modules. Constructors now require explicit serializer instances rather than using optional parameters. Interfaces and options types have been simplified by removing redundant or legacy properties, and some export statements and test cases have been removed. Both the RPC and OpenAPI handlers now directly instantiate their respective codec, matcher, and serializer dependencies using updated signatures, streamlining the module APIs across the client, openapi, and server packages. Changes
Sequence Diagram(s)sequenceDiagram
participant Router
participant OpenAPIHandler
participant OpenAPISerializer
participant OpenAPIMatcher
participant OpenAPICodec
participant StandardHandler
Router->>OpenAPIHandler: Instantiate with router and StandardHandlerOptions
OpenAPIHandler->>OpenAPISerializer: Create serializer instance
OpenAPIHandler->>OpenAPIMatcher: Instantiate matcher
OpenAPIHandler->>OpenAPICodec: Instantiate codec with serializer
OpenAPIHandler->>StandardHandler: Construct handler with matcher, codec, and options
sequenceDiagram
participant Router
participant RPCHandler
participant RPCSerializer
participant RPCMatcher
participant RPCCodec
participant StandardHandler
Router->>RPCHandler: Instantiate with router and StandardHandlerOptions
RPCHandler->>RPCSerializer: Create serializer instance
RPCHandler->>RPCMatcher: Instantiate matcher
RPCHandler->>RPCCodec: Instantiate codec with serializer
RPCHandler->>StandardHandler: Construct handler with matcher, codec, and options
Poem
✨ 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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
More templates
@orpc/client
@orpc/contract
@orpc/openapi
@orpc/react-query
@orpc/server
@orpc/openapi-client
@orpc/shared
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
![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 (3)
packages/openapi/src/adapters/fetch/openapi-handler.ts (1)
14-20: Architecture change: Enforce standard component initializationThe refactoring enforces a standardized way of initializing components across the library, ensuring consistent behavior but at the cost of flexibility. This architectural decision aligns with reducing options as mentioned in the PR title.
Consider documenting this architectural change in the CHANGELOG.md to help users understand the trade-offs made and how to adapt their code accordingly.
packages/server/src/adapters/fetch/rpc-handler.ts (1)
14-18: Consistent dependency instantiation pattern appliedThe fetch adapter's
RPCHandlernow follows the same pattern as the node version, directly instantiating its dependencies (serializer, matcher, codec) rather than allowing them to be optionally passed through options. This consistent approach across adapters improves maintainability.Note that the line 18 has an extra trailing newline that could be removed for consistency with the node adapter implementation, but this is very minor.
const matcher = new RPCMatcher() const codec = new RPCCodec(serializer) - this.standardHandler = new StandardHandler(router, matcher, codec, options)packages/client/src/adapters/fetch/rpc-link.ts (1)
14-17: Direct instantiation of dependencies improves initialization consistency.Instead of using optional properties from options, the constructor now explicitly instantiates:
- A new RPCSerializer
- StandardRPCLinkCodec with the serializer and options
- LinkFetchClient with the options
This change eliminates conditional instantiation logic and ensures consistent initialization, which reduces the risk of undefined dependencies.
Consider adding test coverage for this new initialization pattern to verify the components are properly connected.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
packages/client/src/adapters/fetch/index.ts(1 hunks)packages/client/src/adapters/fetch/rpc-link.ts(1 hunks)packages/client/src/adapters/standard/rpc-link-codec.test.ts(3 hunks)packages/client/src/adapters/standard/rpc-link-codec.ts(4 hunks)packages/openapi/src/adapters/fetch/openapi-handler.test.ts(0 hunks)packages/openapi/src/adapters/fetch/openapi-handler.ts(1 hunks)packages/openapi/src/adapters/node/openapi-handler.test.ts(0 hunks)packages/openapi/src/adapters/node/openapi-handler.ts(1 hunks)packages/openapi/src/adapters/standard/index.ts(0 hunks)packages/openapi/src/adapters/standard/openapi-codec.test.ts(0 hunks)packages/openapi/src/adapters/standard/openapi-codec.ts(1 hunks)packages/openapi/src/adapters/standard/openapi-handler.ts(0 hunks)packages/server/src/adapters/fetch/rpc-handler.test.ts(2 hunks)packages/server/src/adapters/fetch/rpc-handler.ts(1 hunks)packages/server/src/adapters/node/rpc-handler.test.ts(2 hunks)packages/server/src/adapters/node/rpc-handler.ts(1 hunks)packages/server/src/adapters/standard/handler.test.ts(3 hunks)packages/server/src/adapters/standard/handler.ts(1 hunks)packages/server/src/adapters/standard/index.ts(0 hunks)packages/server/src/adapters/standard/rpc-codec.test.ts(1 hunks)packages/server/src/adapters/standard/rpc-codec.ts(1 hunks)packages/server/src/adapters/standard/rpc-handler.ts(0 hunks)
💤 Files with no reviewable changes (7)
- packages/server/src/adapters/standard/index.ts
- packages/openapi/src/adapters/node/openapi-handler.test.ts
- packages/server/src/adapters/standard/rpc-handler.ts
- packages/openapi/src/adapters/standard/openapi-codec.test.ts
- packages/openapi/src/adapters/standard/openapi-handler.ts
- packages/openapi/src/adapters/fetch/openapi-handler.test.ts
- packages/openapi/src/adapters/standard/index.ts
🔇 Additional comments (30)
packages/client/src/adapters/fetch/index.ts (1)
1-1: Adding export for link-fetch-client is a helpful enhancement.This export makes functionality from the 'link-fetch-client' module directly accessible to consumers of the fetch adapter, improving the module's API surface.
packages/server/src/adapters/node/rpc-handler.test.ts (2)
1-1: LGTM: RPCSerializer import added.The import statement for RPCSerializer has been correctly added to support the updated codec instantiation pattern.
116-116: Updated codec instantiation to use explicit serializer dependency.The test now correctly reflects the standardized dependency injection pattern by explicitly providing a RPCSerializer instance to the RPCCodec constructor rather than relying on default parameters.
packages/server/src/adapters/fetch/rpc-handler.test.ts (2)
1-1: LGTM: RPCSerializer import added.The import statement for RPCSerializer has been correctly added to support the updated codec instantiation pattern.
95-95: Updated codec instantiation to use explicit serializer dependency.The test now correctly reflects the standardized dependency injection pattern by explicitly providing a RPCSerializer instance to the RPCCodec constructor rather than relying on default parameters.
packages/server/src/adapters/standard/handler.ts (1)
55-55:Details
✅ Verification successful
Removed default empty object from options parameter.
This change enforces explicit dependency injection by requiring consumers to provide options when creating a StandardHandler. This is consistent with the project's move toward standardized initialization across adapter modules.
Consider verifying that all existing StandardHandler instantiations in the codebase have been updated to explicitly provide options.
🏁 Script executed:
#!/bin/bash # Search for StandardHandler instantiations to verify they all provide options rg "new StandardHandler\(" --type ts -A 5 -B 5Length of output: 9448
Verification: Explicit Options Injection Enforced for StandardHandler
The changes in
packages/server/src/adapters/standard/handler.tsthat remove the default empty object for options have been verified. All StandardHandler instantiations in the codebase—both in production files (e.g., in the fetch, node, and rpc adapters) and in tests—now explicitly provide the options parameter. This ensures that dependency injection is enforced and that missing options result in expected TypeScript errors (as confirmed by the tests).
- Verified instantiations in:
packages/server/src/adapters/fetch/rpc-handler.tspackages/openapi/src/adapters/node/openapi-handler.tspackages/server/src/adapters/standard/handler.test.tsandhandler.test-d.tsNo instances were found where the StandardHandler was instantiated without an explicit options argument.
packages/openapi/src/adapters/standard/openapi-codec.ts (2)
2-2: Import type updated to match constructor changesThe import type for
OpenAPISerializerhas been updated to match the change in dependency injection pattern.
10-12:Details
✅ Verification successful
Breaking change: Constructor now requires explicit serializer parameter
The constructor has been modified to require an explicit
OpenAPISerializerinstance instead of providing a default one. This is a breaking change that enforces explicit dependency injection, which improves testability and makes dependencies clearer, but requires updating all existing instantiations of this class.
🏁 Script executed:
#!/bin/bash # Find all instantiations of OpenAPICodec that might need updating echo "Searching for OpenAPICodec instantiations..." rg "new OpenAPICodec\(" --type tsLength of output: 443
Explicit Serializer Dependency Injection Confirmed
The change requiring an explicit
OpenAPISerializerparameter in theOpenAPICodecconstructor has been fully implemented. All instantiations in the repository now pass the serializer explicitly:
- packages/openapi/src/adapters/node/openapi-handler.ts
- packages/openapi/src/adapters/fetch/openapi-handler.ts
- packages/openapi/src/adapters/standard/openapi-codec.test.ts
This confirms the breaking change has been correctly applied and no further updates are necessary.
packages/server/src/adapters/standard/rpc-codec.test.ts (1)
15-15:Details
✅ Verification successful
Constructor signature change reflected in tests
The test has been updated to use the new constructor signature which now accepts the serializer directly instead of as part of an options object. This matches the pattern of explicit dependency injection implemented across the codebase.
🏁 Script executed:
#!/bin/bash # Check if RPCCodec constructor has been updated accordingly in the implementation echo "Checking RPCCodec implementation for constructor changes..." rg "constructor.*RPCCodec" --type tsLength of output: 167
🏁 Script executed:
#!/bin/bash # Check for RPCCodec class implementation and its constructor signature in the codebase. echo "Searching for class RPCCodec with its constructor in TypeScript files..." rg -A 10 "class RPCCodec" --type tsLength of output: 1202
Constructor Signature Update Verified
The test in
packages/server/src/adapters/standard/rpc-codec.test.tsnow correctly instantiatesRPCCodecwith a direct serializer injection, reflecting the intended constructor change. The implementation inpackages/server/src/adapters/standard/rpc-codec.tsconfirms that the constructor now acceptsserializeras a direct dependency rather than as part of an options object.
- Verified in
rpc-codec.ts: The constructor acceptsprivate readonly serializer: RPCSerializer.- The test’s instantiation
new RPCCodec(serializer)is consistent with this updated signature.packages/client/src/adapters/standard/rpc-link-codec.test.ts (3)
80-85: Constructor signature change consistently appliedThe constructor change has been properly applied to the second instantiation of StandardRPCLinkCodec in the test suite, maintaining consistency.
102-104: Constructor signature change consistently appliedThe constructor change has been properly applied to the third instantiation of StandardRPCLinkCodec in the test suite, maintaining consistency across all test cases.
17-21:Details
❓ Verification inconclusive
Constructor signature simplified with direct serializer parameter
The constructor now accepts the serializer as a direct parameter instead of nested within options. The
rpcSerializeroption appears to have been removed, suggesting a simplification of the API by eliminating redundant parameters.
🏁 Script executed:
#!/bin/bash # Check the StandardRPCLinkCodec implementation to confirm signature changes echo "Checking StandardRPCLinkCodec implementation..." rg "constructor.*StandardRPCLinkCodec" --type tsLength of output: 155
Review Comment Verification: Constructor Simplification
The test snippet now reflects the intended API change where the serializer is passed directly into the constructor. However, our automated search for the constructor signature in the implementation did not yield definitive results, so please manually verify that the implementation (expected inpackages/client/src/adapters/standard/rpc-link-codec.ts) has been updated accordingly—specifically, that it now accepts the serializer as a direct parameter and that any legacy use of therpcSerializeroption has been removed.
- Verify that the constructor signature is updated as described.
- Confirm that all usages of the previous
rpcSerializeroption have been eliminated.packages/openapi/src/adapters/fetch/openapi-handler.ts (3)
3-3: Updated imports to include StandardHandlerOptionsThe import statement has been updated to include
StandardHandlerOptions, reflecting the changes to the constructor signature.
6-6: Added import for OpenAPISerializerA new import for
OpenAPISerializerhas been added to support the direct instantiation of the serializer in the constructor.
14-18:Details
❓ Verification inconclusive
Breaking change: Constructor now directly instantiates dependencies
The constructor has been significantly refactored to:
- Accept
StandardHandlerOptions<T>instead ofOpenAPIHandlerOptions<T>- Directly instantiate the serializer, matcher, and codec instead of accepting them as options
- Pass the serializer to the codec, enforcing the dependency injection pattern
This is a breaking change that removes the ability to customize the matcher and codec through options, standardizing how these components are created and used.
🏁 Script executed:
#!/bin/bash # Search for code that might be using the OpenAPIHandler with custom matcher or codec echo "Searching for potential instances of OpenAPIHandler being created with custom matcher or codec options..." rg "new OpenAPIHandler\(.*\{.*codec" --type ts rg "new OpenAPIHandler\(.*\{.*matcher" --type tsLength of output: 320
Breaking Change Notice: OpenAPIHandler Constructor Refactored
The constructor in
packages/openapi/src/adapters/fetch/openapi-handler.ts(lines 14–18) now directly instantiates its dependencies. This refactoring:
- Changes the constructor to accept
StandardHandlerOptions<T>instead ofOpenAPIHandlerOptions<T>.- Directly creates an
OpenAPISerializer,OpenAPIMatcher, and anOpenAPICodec(with the serializer injected), thereby removing the option to supply custom matcher or codec configurations.- Enforces a set dependency injection pattern that may break any code relying on custom matcher or codec injection.
Initial repository searches did not reveal any usage where custom dependencies were passed to
OpenAPIHandler, but please manually verify that no indirect dependencies or assumptions exist.packages/server/src/adapters/standard/rpc-codec.ts (1)
9-11: LGTM: Constructor now requires explicit serializer dependencyThe constructor signature change improves code clarity by making the
RPCSerializerdependency explicit rather than optional. This change aligns with dependency injection best practices by avoiding implicit instantiation of dependencies.packages/server/src/adapters/standard/handler.test.ts (3)
56-56: Updated constructor call to match new signatureThis change correctly updates the test to match the revised
StandardHandlerconstructor signature that now requires an explicit options object. The empty object satisfies the requirement while maintaining the test's original behavior.
322-322: Correctly updated test to use explicit empty options objectThe test now properly instantiates
StandardHandlerwith all required parameters, including the now-mandatory options object.
340-340: Successfully adapted test to use explicit options parameterThis change maintains consistent usage of the updated
StandardHandlerconstructor across all test cases.packages/server/src/adapters/node/rpc-handler.ts (1)
14-18: Improved dependency management through direct instantiationThis refactoring simplifies the handler's initialization by directly creating its dependencies (serializer, matcher, codec) rather than allowing them to be optionally injected through options. This approach:
- Makes the code more predictable by removing conditional dependency creation
- Eliminates potential bugs from incorrectly configured dependencies
- Creates a clear, consistent initialization pattern
The explicit creation of dependencies with proper constructor arguments is a good practice.
packages/client/src/adapters/fetch/rpc-link.ts (2)
4-4: Expanded imports to explicitly include RPCSerializer.The import statement now includes RPCSerializer, which aligns with the new approach of explicit instantiation rather than optional dependency injection.
7-8: Interface simplification enhances API clarity.The RPCLinkOptions interface has been simplified by removing the optional properties
linkCodecandlinkClient. This change streamlines the interface and makes the API more predictable since these dependencies are now managed internally.packages/openapi/src/adapters/node/openapi-handler.ts (4)
3-3: Import statement updated to include StandardHandlerOptions type.The import now correctly includes StandardHandlerOptions which is used in the constructor signature.
6-6: Explicitly importing OpenAPISerializer for direct instantiation.This new import supports the direct instantiation approach in the constructor.
14-18: Constructor signature simplified with explicit dependency instantiation.The constructor has been updated to:
- Accept a non-optional StandardHandlerOptions parameter with a default empty object value
- Directly instantiate dependencies (serializer, matcher, codec) rather than conditionally using options
- Establish a clear initialization flow with explicit object creation
This approach provides better predictability and removes ambiguity about how components are initialized.
19-19: Simplified StandardHandler initialization.The StandardHandler is now initialized with the options parameter directly instead of spreading it into a new object. This simplification makes the code more readable while maintaining the same functionality.
packages/client/src/adapters/standard/rpc-link-codec.ts (4)
3-3: Modified import for RPCSerializer type.The import has been updated to specifically import the RPCSerializer type, which aligns with its usage as an explicit constructor parameter.
84-84: Updated serializer reference in encode method.The code now correctly uses
this.serializerinstead of the previousthis.rpcSerializerproperty.
128-128: Updated serializer reference in decode method.Similarly, the deserialize method now uses the renamed
this.serializerproperty.
67-70:Details
❓ Verification inconclusive
Constructor signature changed to require explicit serializer dependency.
The constructor now:
- Requires a RPCSerializer instance as the first parameter
- Stores it in a private readonly field
- Enforces explicit dependency injection of the serializer
This change improves type safety and makes the dependency requirements clear at instantiation time rather than through optional interface properties.
Ensure all consumers of this class have been updated to provide a serializer instance. Run:
🏁 Script executed:
#!/bin/bash # Find all instantiations of StandardRPCLinkCodec to verify they provide a serializer rg -A 2 "new StandardRPCLinkCodec" --type typescriptLength of output: 89
Ensure Serializer Dependency Injection is Verified in All Instantiations
The updated constructor signature now explicitly requires a serializer dependency, which improves type safety as noted. However, the initial verification command failed due to an incorrect file type specification. Please re-run the search using a proper glob pattern for TypeScript files to ensure all instantiations of
StandardRPCLinkCodecprovide a serializer. For example, try:#!/bin/bash # Find all instantiations of StandardRPCLinkCodec to verify they provide a serializer rg -A 2 "new StandardRPCLinkCodec" --glob "*.ts"Once this output is manually verified to show that all instantiations conform to the updated constructor signature, the changes can be approved.
dinwwwh
changed the title
1 participant
Summary by CodeRabbit