docs(openapi-fetch): remove line about new examples #2339
Conversation
As discussed in the maintainer's chat: It seems that examples mostly showcase how to integrate an (arbitrary) function/client into a specific framework. As a result, the examples have very little openapi-fetch specific content, but a lot of framework specific content. This, in our opinion, tips the balance of whether the maintenance burden is worth the ease of use.
👷 Deploy request for openapi-ts pending review.Visit the deploys page to approve it
|
|
|
@HasutoSasaki just to kick off the discussion, we (some of the maintainers, @drwpow and I) feel that adding new examples is not worth the maintenance overhead (reviews, keeping it up to date). One big reason behind this is that most examples seem to primarily showcase how to call use an arbitrary async in a specific framework. As such, it is mostly framework documentation and not openapi-fetch documentation. As I'm writing this, I wonder if a middle ground could be to have links to relevant documentation on the framework side. |
|
@gzm0 First of all, thank you for your thoughtful feedback! You’re absolutely right — the example I provided was more about demonstrating how to use openapi-typescript with Nuxt 3, rather than showcasing the library itself. I now understand that including it directly in the project may not be ideal, as it would create ongoing maintenance overhead. That said, I’d like to suggest a possible alternative: what if I host the Nuxt 3 + openapi-typescript example in my own repository, and you link to it from this project? This way, it could still help users without adding any maintenance burden to this repository. |
|
@HasutoSasaki I think that is an excellent idea! I think managing the links to such examples is absolutely within reason for the core maintainers to do. |
|
@gzm0 |
|
@gzm0 |
As discussed in the maintainer's chat: It seems that examples mostly showcase how to integrate an (arbitrary) function/client into a specific framework.
As a result, the examples have very little openapi-fetch specific content, but a lot of framework specific content. This, in our opinion, tips the balance of whether the maintenance burden is worth the ease of use.