docs: improve comparison for tRPC #282
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe pull request updates a documentation file by modifying the feature support table. The changes adjust the statuses for various tRPC functionalities, such as end-to-end errors and file/blob typesafe, server actions support, lazy routing, native types, plugins, dedicated Zod schemas, and usage of native modules. No public exports were altered. Changes
Possibly related PRs
🪧 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 (
|
|
Thank you, @Nick-Lucas, for your openness on this issue. However, I have a few points of disagreement in this PR:
If I remember correctly, tRPC not support something like this:
tRPC only displays data as form-data and does not show actual File/Blob instances. |
unnoq
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
I think we have two separate approaches, but the tRPC errorFormatter definitely would allow you to include a type like
We need to document this better, File and Blob are just ReadableStreams under the hood, so we provide octetInputParser as a utility which can be wrapped up to provide type safety there, but by default you're right it exposes ReadableStream on the server-side and that's not feature-complete. Still misleading to say we don't support it at all, we do but I could accept a 🟡 |
|
Approved @Nick-Lucas, please fix the lint issues |
![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 (2)
apps/content/docs/comparison.md (2)
17-17: Confirm Accuracy of "End-to-end Errors Typesafe" Status for tRPC
The updated status for tRPC is now marked as supported (✅). Please verify that this accurately reflects tRPC’s current error handling capabilities. If there are known limitations or if type-safety is only partially supported (as some documentation debates suggest), consider adjusting the status accordingly (e.g., to 🟡).
34-34: Clarify "Dedicated Zod Schemas" Status for tRPC
tRPC is now marked as N/A for dedicated Zod schemas. If this classification might be confusing to readers, consider adding a brief explanatory note in the documentation to clarify why dedicated Zod schemas are not applicable for tRPC.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/content/docs/comparison.md(2 hunks)
🔇 Additional comments (6)
apps/content/docs/comparison.md (6)
18-18: Verify "End-to-end File/Blob Typesafe" Update for tRPC
The new entry indicates full support (✅) for file/blob types. Please ensure that this status correctly reflects how tRPC now handles File/Blob instances (leveraging ReadableStreams and utilities like octetInputParser) and that there are no caveats unaddressed in the documentation.
28-28: Review "Server Actions Support" Status Update
tRPC is now marked as fully supporting Server Actions (✅). Confirm that this change aligns with the latest updates and that no aspects of the implementation require a note about partial support.
29-29: Confirm "Lazy Router" Capability for tRPC
With the status now set to supported (✅), please verify that this accurately represents tRPC’s lazy routing features as per the latest release notes and documentation.
30-30: Validate "Native Types" Support for tRPC
The table now shows full support (✅) for native types (e.g., Date, URL, Set, Maps) in tRPC. Please double-check that all these native types are indeed natively handled in the current version of tRPC.
33-33: Confirm "Plugins-able (CORS, ...)" Integration for tRPC
The updated row indicates that tRPC supports plugin-based integrations such as CORS (✅). Verify that this accurately mirrors the feature's implementation, particularly noting that CORS is managed at the adapter level rather than internally.
35-35: Review "Use Native Modules on Each Runtime" Status for tRPC
The table now shows tRPC with full support (✅) for using native modules, in contrast to ts-rest’s partial support (🟡). Please confirm that this comparison accurately reflects the implementation details and, if necessary, consider adding context to explain the distinction.
Looks sorted now |
Updated comparison table to more accurately reflect what tRPC can do.
Right now it makes an assumption that being coupled in several areas leads to tRPC being worse in those areas, whereas tRPC does provide out the box support but allows you to choose the library (ie. for transformers, cors) you use.
tRPC is mounted inside an adapter which may be a native http module or an adapter inside of express or many other web servers, this means CORS is natively supported but at the adapter level rather than trying to handle that itself
Things like Lazy routers are actually more recent additions so this is a timely update there :)
Summary by CodeRabbit
Summary by CodeRabbit