Show & Tell: vue-muza-use — a typescript-first composable API layer for Vue 3

[MortyQ]

vue-muza-use — a small, opinionated data fetching layer for Vue 3

When I started building vue-muza-use, the goal was not to make “another request hook”.
The goal was much simpler and much stricter: remove the repetitive API wiring from Vue components and leave only what actually matters for the UI — data, state, and behavior. 😅

In short, vue-muza-use is a small, TypeScript-first layer on top of Axios for Vue 3 that helps you:

• avoid writing the same watch + execute + loading pattern in every component;
• automatically refetch when reactive dependencies change;
• work with cache, SWR, polling, retries, and refetch triggers without manual wiring;
• keep request logic close to the data instead of spreading it across components. 🔁

What it solves

In real Vue projects, data fetching becomes repetitive very quickly.

At first, you just make a request.
Then you add loading.
Then you need watch for filters.
Then execute().
Then cache.
Then refetch on tab focus.
Then reconnect handling.
Then manual control so this whole thing doesn’t break in 15 different components. 😵‍💫

At that point, the problem is no longer Axios itself.
The problem is the extra layer of repeated request logic you keep rebuilding around it.

That is exactly what I wanted to remove.

How it looks

The core idea is simple: you describe what the UI needs, and the library handles the request mechanics.

const search = ref('')

const { data, loading, error } = useApi('/products', {
  params: () => ({ q: search.value }),
})

If search.value changes, the request refetches automatically.
No separate watch.
No manual execute() wiring.
No need to remember one more dependency every time. ⚡

For me, that is the right mental model: the component should describe the data it needs, not how to repeatedly fetch it.

Why I built it

Because manual watch logic inside API flows becomes annoying very fast.

It usually breaks not because watch is bad by itself, but because in a real project:

• someone forgets to add a dependency;
• someone adds the wrong one;
• someone adds too many and gets extra refetches;
• the logic gets moved into another layer and becomes harder to reason about;
• the same pattern gets duplicated across dozens of components.

This is especially painful in tables, filters, dashboards, and any UI where a request depends on multiple reactive values. 🧩

With vue-muza-use, I wanted that whole class of problems to disappear from the common case.

What I like about the approach

1. Auto-tracking of dependencies

If a reactive value is used inside url, params, or data, the request refetches automatically.
That removes a lot of manual code and makes behavior much more predictable. 🔁

2. lazy for manual control

Not everything should be automatic.
For forms, submit flows, and cases where you want precise control, there is lazy: true.
So the library does not force you into only one execution model.

3. SWR and cache

For UX, this is one of the most useful parts.
Users should not stare at a blank screen or spinner if data already exists and can be shown immediately. ⚡

4. Refetch on focus and reconnect

This is what makes the UI feel alive.
Come back to the tab — data refreshes.
Connection returns — data refreshes.
The user should not have to manually click refresh in obvious scenarios. 📡

5. TypeScript-first API

I intentionally try to keep types as the base of the API, not as an afterthought.
If a library is for Vue 3 and TypeScript, it should not feel like a JS wrapper with types added later.

Honest trade-offs

I do not like pretending a library only has advantages.
That is a weak approach.

1. It is opinionated

vue-muza-use does not try to be a universal solution for everything.
It is built around a specific way of handling data fetching in Vue 3.
That will be great for some people and too opinionated for others.

2. It is not a replacement for everything

If you want a huge query layer with a much larger ecosystem, this library may feel too focused.
It is not trying to win by size.
It is trying to stay clean and practical.

3. Trust takes time

A small library always has the trust problem:

• what if the author disappears?
• what if the API changes again?
• what if this is just a one-off project?

That is a real risk.
That is why I care about stable API decisions, solid tests, and predictable behavior. ✅

Who it fits

vue-muza-use fits well if you:

• build with Vue 3;
• use TypeScript;
• want to remove repetitive request mechanics;
• work with filters, tables, dashboards, feeds, and forms;
• want a predictable data layer without extra magic. 🧠

Who it may not fit

It may not fit if you:

• want a maximally abstract solution for every possible case;
• dislike opinionated APIs;
• already use another mature query solution and do not want to change;
• expect the library to hide absolutely everything.

And that is fine.
Not every library should fit everyone.

What is next

Right now, I am looking into a few things:

• Vue DevTools integration;
• playground documentation;
• a better experience for people working with AI agents;
• easier debugging and better visibility into request state.

For me, vue-muza-use is not “a package for the sake of a package”.
It is an attempt to make data fetching in Vue more honest, more transparent, and less annoying. 🚀

If you want to check it out:

https://www.npmjs.com/package/@ametie/vue-muza-use