feat: add OpenAPI Operation invoke method

[radist2s]

Added the ability to execute GET, POST, and other HTTP operations directly on OpenAPI endpoints via Qraft. This enhancement enables streamlined interaction with APIs, allowing users to configure parameters and base URL seamlessly.

Examples:

• Fetching posts with specified limits:

  const posts = await qraft.posts.getPosts({
  parameters: { query: { limit: 10 } },
  baseUrl: 'https://api.sandbox.monite.com/v1',
  }, requestFn);

• Updating a post title using a post ID:

  const updateResponse = await qraft.posts.updatePost({
  parameters: { path: { post_id: 123 } },
  body: { title: 'New title' },
  baseUrl: 'https://api.sandbox.monite.com/v1',
  }, requestFn);

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: ebafaa23d5ddaa77a322e10067454240fcff2586

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

| Name | Type | | ------------------------------------------ | ----- | | @openapi-qraft/tanstack-query-react-plugin | Minor | | @openapi-qraft/react | Minor | | @openapi-qraft/cli | Minor | | @openapi-qraft/plugin | Minor |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions[bot]]

@check-spelling-bot Report

:red_circle: Please review

See the :open_file_folder: files view, the :scroll:action log, or :memo: job summary for details.

Unrecognized words (1)

TOptions

To accept these unrecognized words as correct, you could run the following commands

... in a clone of the [git@github.com:OpenAPI-Qraft/openapi-qraft.git](https://github.com/OpenAPI-Qraft/openapi-qraft.git) repository on the `feature/operation-invoke-fn` branch ([:information_source: how do I use this?]( https://github.com/check-spelling/check-spelling/wiki/Accepting-Suggestions)): ``` sh curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/v0.0.22/apply.pl' | perl - 'https://github.com/OpenAPI-Qraft/openapi-qraft/actions/runs/8769666111/attempts/1' ```

OR

To have the bot accept them for you, reply quoting the following line: @check-spelling-bot apply updates.

Available :books: dictionaries could cover words (expected and unrecognized) not in the :blue_book: dictionary

This includes both **expected items** (80) from .github/actions/spelling/expect.txt and **unrecognized words** (1) Dictionary | Entries | Covers | Uniquely -|-|-|- [cspell:aws/aws.txt](https://raw.githubusercontent.com/check-spelling/cspell-dicts/v20230509/dictionaries/aws/aws.txt)|218|6|3| [cspell:k8s/dict/k8s.txt](https://raw.githubusercontent.com/check-spelling/cspell-dicts/v20230509/dictionaries/k8s/dict/k8s.txt)|153|4|2| [cspell:dotnet/dict/dotnet.txt](https://raw.githubusercontent.com/check-spelling/cspell-dicts/v20230509/dictionaries/dotnet/dict/dotnet.txt)|405|4|2| [cspell:python/src/python/python-lib.txt](https://raw.githubusercontent.com/check-spelling/cspell-dicts/v20230509/dictionaries/python/src/python/python-lib.txt)|2417|3|2| [cspell:php/dict/php.txt](https://raw.githubusercontent.com/check-spelling/cspell-dicts/v20230509/dictionaries/php/dict/php.txt)|1689|2|1| Consider adding them (in `.github/workflows/spelling.yml`) for `uses: check-spelling/check-spelling@v0.0.22` in its `with`: ``` yml with: extra_dictionaries: cspell:aws/aws.txt cspell:k8s/dict/k8s.txt cspell:dotnet/dict/dotnet.txt cspell:python/src/python/python-lib.txt cspell:php/dict/php.txt ``` To stop checking additional dictionaries, add (in `.github/workflows/spelling.yml`) for `uses: check-spelling/check-spelling@v0.0.22` in its `with`: ``` yml check_extra_dictionaries: '' ```

[radist2s]

@raducal, thanks for the feedback, which motivated me to make this PR.

[raducal]

@radist2s Thank you, awesome stuff!

It would be cool if the baseUrl and the requestFn weren't required. Maybe in a future update, the baseUrl and the requestFn could be something we can pass to our createAPIClient. It makes sense to make baseUrl optional if you go down this route in case a particular call required a different baseUrl

[radist2s]

@raducal, this is exactly how the Vanilla client will be implemented. The main problem with the inability to pass baseUrl when calling createAPIClient(...) for React is that then it will be necessary to pass the created client through React Context if we are talking about SSR support, for example in Next.js.

Also, for different cases, it may be necessary to somehow specify authorization headers that depend on the state. This would require re-creating the client for different cases, which is not optimal.

[raducal]

@radist2s I see. I think I would be totally ok with passing the client returned from createAPIClient to the react context. Do you see any issues with that?

requestFn on these invocable operations can also be left so users can handle headers and whatnot whatever way they would like to, but I think making it optional would be good since I think most of the time they would probably be handled the default way, which would be defined by the requestFn.

[radist2s]

@raducal, thanks, there's a lot to think about here. I would like to try to implement a type that would check whether specific parameters were passed, in order to make them optional, or require them to be passed when calling target functions. Then, it would be possible to close the issue of the need to pass parameters and QueryClient once and for all. True, I’m not sure that the resulting type will be optimal for a DX performance.