-
-
Notifications
You must be signed in to change notification settings - Fork 112
docs(digging-deeper:tuyau): first draft of documentation #194
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
Conversation
Thankssss
was wondering, what about adding a new "RPC" section in the sidebar that would include "Installation" / "Superjson" / "Inertia" / "RPC client" instead of putting everything on a single page?
"RPC" is probably not the best term, but I don’t have a better idea right now. The thing is, by trying to keep everything on a single page, I feel like we’re leaving out a lot of important information
Also, here are some other things i would love to keep in the docs:
- An intro section briefly explaining the purpose of Tuyau. Not everyone is super familiar with the concept. It would also be nice to include the StackBlitz demo, allowing people to have a quick peek :
https://tuyau.julr.dev/docs/introduction#e2erpc-like-client-what-does-that-mean - A section explaining HOW it works:
https://tuyau.julr.dev/docs/introduction#how-does-it-work
I think this is super important for debugging and understanding why something might not be working. - A part about unwrapping and narrowing errors/responses:
https://tuyau.julr.dev/docs/client#responses - And more... In fact, a lot of things have been stripped out from the original docs, and I think many of them were actually important
Lemme know your opinions
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.
Small nitpick. But we shouldn't have semi-colons in the code examples.
A thought.
Instead of having the doc title as "Tayau Client", should we instead write the doc for "Type-safe client" or something similar? This is because, no one will look at the title Tayau
and understand what it is. Whereas, seeing a Type-safe client is far more relatable.
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.
There is a ?
before FormData
that seems like a typo.
Also, can we link to object-to-formdata
package for easier navigation?
A thought.
Instead of having the doc title as "Tayau Client", should we instead write the doc for "Type-safe client" or something similar? This is because, no one will look at the title
Tayau
and understand what it is. Whereas, seeing a Type-safe client is far more relatable.
Yeah probably but I’m not sure if "Type-safe client" is the right fit since Tuyau does have a Type-safe RPC/E2E client part, but that’s not all. there’s also our ziggy
-like system for frontend URL generation, helpers for Inertia...
But I don’t have a better name to suggest right now 😅
Deploying v6-docs with Cloudflare Pages Cloudflare Pages
8c5496f
I generally favor consolidating content on a single page to enhance user experience, as it reduces the need to navigate between pages to find information. However, if you prefer organizing the section across multiple pages, we can proceed that way, acknowledging it may slightly impact UX due to the increased page transitions.
Regarding the section’s title, if the current name isn’t sufficiently descriptive, we could consider renaming it to something like E2E Type-Safety
.
The current approach aligns with other sections such as Transmit
, Vite
, or Ace
, which don't explicitly convey their contents, yet users adapt to them. Therefore, I believe the current naming convention isn’t a significant issue.
Uh oh!
There was an error while loading. Please reload this page.
Hey! 👋🏻
This PR adds the documentation for the Tuyau package.
The following are still missing:
InferRequest
/InferResponse
$current
,$has
methodsAdditionally, the current Tuyau documentation includes a brief section on Next.js, which acts more like a tutorial for building a monorepo with Next.js, AdonisJS, and Tuyau for type-safe client-side development. I think this content would be better suited as an article for our blog, which we could link to from the documentation.