docs(digging-deeper:tuyau): first draft of documentation

[RomainLanz]

Hey! 👋🏻

This PR adds the documentation for the Tuyau package.

The following are still missing:

• [ ] InferRequest / InferResponse
• [ ] $current, $has methods
• [ ] Filtering of generated types/routes
• [ ] Some notes or tips on improving type-safety (e.g., DTOs, presenters, viewmodels)

Additionally, 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.

[Julien-R44]

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

[thetutlage]

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.

[Julien-R44]

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 😅

[cloudflare-workers-and-pages[bot]]

Deploying v6-docs with    Cloudflare Pages

Latest commit:	8c5496f
Status:	✅  Deploy successful!
Preview URL:	https://0bb3c7ef.v6-docs.pages.dev
Branch Preview URL:	https://doc-tuyau.v6-docs.pages.dev

View logs

[RomainLanz]

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.