vue3-request: one hook for the async state every screen repeats

One hook, six pieces of state

The core claim is unified state management, and the list of state is worth reading carefully because it is more than the usual four.

All the data is reactive, and the library manages loading, data, res, error, signal and params automatically. That is six names for what a hand-rolled version of this pattern usually spreads across three or four separate variables. The response and the data are separate, which is the detail that tells you the author has thought about a real case, since for a request that returns a body and a status code you want both, and in a single data variable you have to pick one.

The signal is the abort signal for the request, and it is exposed rather than hidden, which is the thing that makes cancellation work in a component that owns the request.

The methods cover the operations you would otherwise write by hand. There is run for the normal case, runAsync when you want a promise, refresh to repeat the last request, and cancel and abort for stopping it.

The last feature is the one that decides whether the hook fits your component. It supports both manual and automatic execution, so the request can fire when the component mounts or only when you call run. A screen with a filter that should not fetch until the user picks a value and a screen that fetches on mount are the same hook with a different mode, and having the mode as a parameter rather than as a copy of the whole call is what removes the duplication.

The package describes itself as framework-agnostic as well, which is a larger claim than it looks, since the implementation is a Vue composable. In practice that means the request logic is not tied to a component's template, so it can be used in a store.

Nine plugins for the problems that repeat

The plugin list is the real feature set, and it reads like a list of bugs people have filed.

There are nine built-in core plugins, described as ready to use out of the box. The first is request abort, which wires the abort signal into the lifecycle so that a request is cancelled when it is no longer wanted. The second is error retry, which is the behaviour almost every hand-rolled fetch lacks and every production app needs.

Then there is debouncing and throttling, so a search box does not fire a request per keystroke, and a smart cache, which is the plugin that decides when a response can be reused and when it must be refetched.

The polling plugin covers the dashboards that need to refresh on a timer, and the window focus refresh plugin covers the other common case, refetching when the user comes back to the tab and the data may be stale. The dependency refresh plugin lets one request depend on another's result, so a second request fires when the first completes.

The last one is ready-state control, which is about not running the request until some condition is met, and which pairs with the manual execution mode.

The rest of the list is more about the shape of the library than its features: full TypeScript support, being framework-agnostic, a rich set of lifecycle hooks, an extensible architecture, and thorough documentation.

The architecture claim is the one that matters for the long term. A plugin system means the behaviours above are not hard-coded into the hook, so the library can grow without breaking the API, and a project can add its own plugin for the request pattern that is peculiar to it. The trade is that a plugin is another layer between you and the request, and a behaviour that is not obvious from the hook call is a behaviour you will have to look up.

The whole API in one line of a component

The quick start example is a single file component, and the readme is explicit that one line handles the state management.

const { data, error, loading, signal, refresh, abort } = useRequest(getUserInfo);

The template that goes with it branches on loading, then on error, then renders the data, with a button bound to refresh and another to abort.

The important detail in the example is in the request function itself. It is a plain async function that reads the abort signal from the hook result and passes it to fetch, so the cancellation works because the hook owns the signal and the caller uses it. That is a good contract, because it means the library does not have to wrap or patch fetch, and any HTTP client that accepts an abort signal will work.

The pattern is the familiar one, then. You write the request, you hand it to the hook, you destructure what you need, and the template renders the three states. What you no longer write is the loading flag, the error variable, the try and catch, the abort controller, the refresh function and the reset-on-unmount logic.

That is a fair trade for a screen that fetches once. It is a very good trade for an application with twenty screens that all do it slightly differently.

Installing it, and the playground

The install is four commands, one per package manager.

pnpm add vue3-request
npm i vue3-request
yarn add vue3-request
cnpm i vue3-request

That the list includes the Chinese mirror client is a small indicator of where the library is used, and it costs nothing to include.

The readme points to a documentation site for more content and to an online playground built on CodeSandbox, which is the fastest way to evaluate a library like this. The playground matters more here than usual, because the question with a request hook is not what the API looks like but how the behaviour feels in a component, and a sandbox lets you type into a fake endpoint and watch the loading, error and cancel states without setting anything up.

The project also describes itself as small and elegant, in both the English and Chinese descriptions, with the claim that complex asynchronous logic becomes simple and repetitive boilerplate becomes history.

That is the sales pitch. The fair test is the plugin list, because that is where the complexity went: the hook is simple because the complexity is in nine composable pieces that you opt into, and the real question for an evaluator is how many of those nine your application already has a hand-rolled version of.

The packaging is modern and the licensing is unclear

The manifest is a good example of a package that has been built with the modern toolchain in mind.

The package is an ES module, with a main entry pointing at the bundled ES file, a types entry for the type declarations, and an unpkg field for the UMD build. The exports map has separate browser, types, import and require conditions, so a bundler gets the ES module, a CommonJS consumer gets the CJS file, and a script tag gets the UMD build. The published files list contains only the dist directory, which keeps the package small.

The build is Vite, and the release process is a script that takes a level argument, patch, minor or major, rather than a hand-edited version bump. That matters for a library with a rapid release history, because it means the version in the manifest and the tag on the repository cannot drift apart.

The licence is the one loose end. The repository listing does not state a licence, but the published manifest declares ISC, which is a permissive short-form licence. Those two statements are not in conflict, but the repository is the place a reader looks first, and for a package you are about to depend on in a commercial product, the file that is actually shipped is the one to read. The other metadata is a normal set: the homepage points at the author's GitHub profile, the repository URL is the project itself, and the keywords list the things a search would use to find it.

The single release in the history is version 1.0.33 from 2025-08-25, with the last push on 2026-10-19, so the work is ongoing even though the version number has not moved in a while.

A workspace with the library and its docs side by side

The repository is a pnpm workspace, and looking at the scripts tells you how it is put together.

The package names in the workspace filters are scoped, with a package for the Vue 3 library and a package for the documentation site. There are parallel development scripts that run both at once, or one at a time, and matching build and serve scripts for the documentation. There is a cleanup script, rf, that removes the node modules, the dist directory and the per-package artefacts, and it sits in the package manifest next to the other scripts.

The release scripts all call the same node script with a level argument, so publishing a patch, a minor or a major is the same command with a different word, and the version bump is handled by the script.

The rest of the tree is conventional for a modern TypeScript library: a build directory, a packages directory, a scripts directory, a tools directory, a Vite configuration, a TypeScript configuration, a workspace file, a lock file, and an editor configuration. There are also directories for agent instructions and editor rules, which tells you the project is developed with AI coding assistants in the loop, and an agent instructions file at the root.

The documentation site is part of the workspace rather than a separate repository, which is the right arrangement for a library whose documentation includes live examples. A playground that is built from the same source as the library can drift from it, and putting the two in one workspace with one build pipeline is how you stop that.

Editorial conclusion

vue3-request suits a Vue 3 codebase where the same request patterns appear on many screens, because the plugin list covers the cases that are usually copy-pasted per component. It is a poor fit for an application with one simple fetch, where the hook is more machinery than the problem, and it is a poor fit if you need to control the exact request lifecycle yourself, since the library is built around running a function. Before you adopt it, read the plugin documentation for the behaviours you already implement, check that the licence in the published package matches what you need, since the manifest declares ISC while the repository listing does not state one, and confirm the version you install is the one whose behaviour you have read about.

Frequently asked questions

Official sources

1. Flame-00/vue3-request on GitHub
2. Issues
3. Project website
4. README
5. Releases