DEV Community: Scott Hu

From Axios to alova: how we cut 80 lines to 5

Scott Hu — Mon, 01 Jun 2026 03:35:01 +0000

Frontend request code often involves repetitive state management. This article compares Axios and alova through a paginated list example, analyzing how request strategization reduces boilerplate and when it's a good fit.

The Pattern: Paginated List in Two Ways

A common requirement: fetch a user list with pagination.

Approach 1: Axios

const [data, setData] = useState([]);
const [page, setPage] = useState(1);
const [total, setTotal] = useState(0);
const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

const fetchUsers = async (currentPage) => {
  setLoading(true);
  setError(null);
  try {
    const res = await axios.get('/api/users', {
      params: { page: currentPage, pageSize: 10 },
    });
    setData(res.data.list);
    setTotal(res.data.total);
  } catch (e) {
    setError(e.message);
  } finally {
    setLoading(false);
  }
};

useEffect(() => { fetchUsers(page); }, [page]);

This pattern appears in nearly every data-fetching component. The actual business logic — GET /api/users — occupies a single line. The rest is infrastructure: state declarations, loading toggles, error handling, and effect management.

Approach 2: alova with usePagination

const {
  data, total, loading, error,
  page, pageSize, nextPage, prevPage,
} = usePagination(
  (page, pageSize) => alovaInstance.Get('/api/users', {
    params: { page, pageSize },
  }),
  { page: 1, pageSize: 10 }
);

Both implementations are functionally identical. The key difference is where the state management logic lives: in the component (Axios) vs. inside the hook (alova).

What Changed

Component of Axios version	Handled by alova
`loading` state + toggling	Managed internally by usePagination
`error` state + try/catch	Managed internally by usePagination
`data` state + assignment	Returned as reactive value
`page` state + change handler	Built-in `nextPage` / `prevPage`
`total` state extraction	Extracted from response automatically
useEffect dependency tracking	Managed internally

The removed code shares one characteristic: it's infrastructure for the request pattern, not business logic. alova encapsulates this infrastructure into scenario-specific hooks.

Beyond Pagination

alova provides hooks for common request patterns:

useRequest — basic fetch

// Auto-fetch on mount
const { data, loading, error } = useRequest(getUserList());

// Manual trigger
const { send } = useRequest(createOrder, { immediate: false });

useWatcher — reactive fetch with debounce

const { data } = useWatcher(
  () => searchApi(keyword.value),
  [keyword],
  { debounce: 300 }
);

useForm — form submission

const { form, loading, send: submit, reset } = useForm(
  submitApi,
  { initialForm: { name: '', email: '' } }
);

All hooks share a consistent return interface (data, loading, error) while adding scenario-specific capabilities.

Code reduction across six common scenarios:

Scenario	Axios (core lines)	alova (core lines)	Reduction
Paginated list	~30	6	~80%
Search with debounce	~25	3	~88%
Form submission	~30	3	~90%
Polling / auto-refresh	~25	3	~88%
Chained requests	~30	5	~83%
File upload	~35	8	~77%

Line counts reflect core logic only, excluding UI rendering and imports.

When to Use (And When Not To)

Good fit for:

Medium-to-large projects with many data-fetching pages
Teams wanting consistent request patterns across codebase
New projects where the abstraction can be established early

Less suitable for:

Small projects where the abstraction overhead outweighs the benefit
Teams already deeply invested in React Query or SWR — evaluate migration cost carefully
Non-standard request patterns that don't map well to existing hooks
Framework ecosystems outside of React/Vue/Svelte support

Other considerations:

Learning curve: Understanding the strategy hook paradigm takes initial investment
Debugging: The abstraction layer can add indirection when troubleshooting unexpected behavior
Ecosystem: alova's community and third-party integrations are smaller than Axios'
Migration path: The Method API mirrors Axios, enabling incremental adoption

// Nearly identical API
axios.get('/api/users', { params: { page: 1 } });
alovaInstance.Get('/api/users', { params: { page: 1 } });

Summary

Moving from Axios to alova is not about "switching HTTP libraries." It's about treating requests as composable scenarios rather than one-shot operations you wire up manually. Whether this abstraction is valuable depends on your project's specific needs — the code reduction is real, but so are the trade-offs.

Stop writing useEffect for data fetching. Use Request Strategies instead.

Scott Hu — Sat, 30 May 2026 12:16:45 +0000

⚠️ 【Draft – Pending Review】

Stop writing useEffect for data fetching. Use Request Strategies instead.

I've been a React developer for about three years. And for most of that time, I wrote data fetching the same way everyone else did:

useEffect(() => {
  fetch('/api/users')
    .then(res => res.json())
    .then(setData)
    .catch(setError)
    .finally(() => setLoading(false));
}, []);

It works. But it's not good.

Every list page. Every search box. Every filter. Same pattern. And the code kept growing — loading states, error handling, debounce timers, race condition flags. A simple user list with search would easily hit 80 lines of boilerplate.

Then I found alova, and I realized: I'd been fighting problems that didn't need to exist.

The Before: useEffect Hell

Here's what my code used to look like:

// 🔴 Before: 80 lines of manual state management
import { useState, useEffect, useCallback } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);
  const [keyword, setKeyword] = useState('');
  const [page, setPage] = useState(1);

  const fetchUsers = useCallback(async () => {
    setLoading(true);
    setError(null);
    try {
      const res = await fetch(`/api/users?keyword=${keyword}&page=${page}&pageSize=10`);
      const data = await res.json();
      setUsers(data.list);
    } catch (err) {
      setError(err.message);
    } finally {
      setLoading(false);
    }
  }, [keyword, page]);

  useEffect(() => { fetchUsers(); }, [fetchUsers]);

  // Manual debounce
  useEffect(() => {
    const t = setTimeout(() => fetchUsers(), 500);
    return () => clearTimeout(t);
  }, [keyword]);

  // Manual race condition handling
  useEffect(() => {
    let cancelled = false;
    fetch(`/api/users?keyword=${keyword}&page=${page}`)
      .then(res => res.json())
      .then(data => { if (!cancelled) setUsers(data.list); });
    return () => { cancelled = true; };
  }, [keyword, page]);

  if (loading) return <Spinner />;
  if (error) return <Error msg={error} />;

  return (
    <div>
      <SearchInput value={keyword} onChange={setKeyword} />
      <UserList data={users} />
    </div>
  );
}

This code has several issues:

Too many manual states — loading, error, data all declared by hand
DIY debounce — setTimeout/clearTimeout everywhere, easy to mess up
Race conditions — the classic cancelled flag pattern, error-prone
Dependency chains — useCallback + useEffect, changing one prop means tracing the whole chain

I wrote this pattern dozens of times. Every new project, same boilerplate.

The After: Request Strategies with alova

Then I switched to alova, and the same component became this:

// 🟢 After: 15 lines with alova request strategies
import { useRequest, useWatcher } from 'alova/client';
import { alovaInstance } from './api';

function UserList() {
  const [keyword, setKeyword] = useState('');

  // List data — auto-managed loading/data/error
  const { loading, data: users = [], error } = useRequest(
    () => alovaInstance.Get('/api/users', {
      params: { page: 1, pageSize: 10 }
    }),
    { initialData: [] }
  );

  // Search — debounce + race condition handling built in
  const { data: searchResult = [] } = useWatcher(
    () => alovaInstance.Get('/api/users', {
      params: { keyword, page: 1, pageSize: 10 }
    }),
    [keyword],
    { debounce: 500 }
  );

  if (loading) return <Spinner />;
  if (error) return <Error msg={error.message} />;

  return (
    <div>
      <SearchInput value={keyword} onChange={setKeyword} />
      <UserList data={users} />
    </div>
  );
}

This isn't magic. It's design.

alova transforms data fetching from imperative to declarative. Instead of telling the computer how to fetch, you tell it what to fetch — and the library handles the rest.

What you used to write by hand	What alova does for you
3x `useState` for loading/data/error	`useRequest` returns them automatically
`useEffect` + `useCallback` chains	Declarative watchers with auto dependency management
`setTimeout` / `clearTimeout` for debounce	`debounce: 500` — one line
`cancelled` flag for race conditions	Built-in abort on next request
Manual URL parameter construction	`params` object, auto-serialized

What Are "Request Strategies"?

alova isn't a simple fetch wrapper. It's a strategy-based request library that covers the most common data-fetching patterns in frontend development:

Strategy Hook	You tell it	It handles
`useRequest`	What to fetch	loading, data, error, send, abort
`useWatcher`	What state to watch	debounce, auto-refetch, race conditions
`usePagination`	Page config	Page state, preloading, optimistic updates
`useForm`	Form data	Draft persistence, auto-submit, reset
`useAutoRequest`	Polling config	Auto-polling, focus refresh, reconnect
`useCaptcha`	Phone number	Countdown timer, auto-send
`useSerialRequest`	Dependent calls	Pass previous result to next request
`useRetriableRequest`	Retry config	Exponential backoff with jitter

Each hook maps to a pattern you've probably implemented dozens of times. The goal isn't to write less code — it's to not write it at all.

The Results

After switching to alova across my projects, here's what I've seen:

60% less boilerplate — pages went from ~150 lines to ~60 lines
Fewer bugs — no more "forgot to clearTimeout" or "wrong cancelled flag"
Faster onboarding — new devs learn "use this hook for this pattern" instead of debugging useEffect chains
Better code review — request logic is declarative and self-documenting

Getting Started

npm install alova

Then pick an adapter:

npm install @alova/fetch     # For browsers / Node.js
npm install alova/axios       # If you're on axios

And write your first strategic request:

import { createAlova } from 'alova';
import fetchAdapter from '@alova/fetch';
import ReactHook from 'alova/react';

export const alovaInstance = createAlova({
  baseURL: 'https://api.example.com',
  statesHook: ReactHook,
  requestAdapter: fetchAdapter(),
  responded: res => res.json()
});

// In your component:
function Profile() {
  const { loading, data, error } = useRequest(
    () => alovaInstance.Get('/user/profile'),
    { initialData: {} }
  );
  // ...
}

Stop writing useEffect for data fetching. Your time is better spent on actual product logic.

Give alova a try. The docs are at alova.js.org, the source is on GitHub, and the community is welcoming.

Using alova v3. Tested in React, Vue, and Svelte.

Hello Dev.to - Test Post

Scott Hu — Sat, 30 May 2026 07:11:57 +0000

Hello Dev.to

This is a test post to verify the API publishing flow works.

Nothing fancy, just making sure everything is wired up correctly.

Thanks for stopping by!

文章标题23

Scott Hu — Sat, 30 May 2026 05:59:25 +0000

文章内容 markdown

文章标题

Scott Hu — Sat, 30 May 2026 05:57:54 +0000

文章内容（markdown）

I replaced TanStack Query with alova and cut my code by 70%

Scott Hu — Fri, 29 May 2026 08:41:33 +0000

I replaced TanStack Query with alova and cut my code by 70%

A frontend engineer's real-world migration story — 5 scenarios, 133 lines reduced to 10 (92.5% reduction)

Six months ago I took over a mid-office project with a wishlist the size of a CVS receipt: paginated lists, multi-step forms, real-time SSE notifications, file uploads, autocomplete search…

Naturally, I reached for TanStack Query (formerly React Query). It's the de facto standard for React data fetching, right?

But as the project grew, something felt off. To handle different request patterns, I kept wrapping TanStack Query with more and more custom logic:

Pagination? Write useInfiniteQuery + manually manage page state + flatten pages with flatMap.
Forms? useMutation handles submission only — form state, draft saving, reset, all DIY.
SSE? TanStack Query doesn't support it. I pulled in @microsoft/fetch-event-source.
Server-side retry? TanStack Query is client-only.

By the end, I counted 2,000+ lines of request-related code.

Then a colleague dropped a link: alova.

First shock: Pagination went from 50 lines to 3

Before: TanStack Query

import { useInfiniteQuery } from '@tanstack/react-query'

const PAGE_SIZE = 10

function TodoList() {
  const {
    data, fetchNextPage, hasNextPage,
    isFetchingNextPage, isLoading, isError, error,
  } = useInfiniteQuery({
    queryKey: ['todos'],
    queryFn: async ({ pageParam = 1 }) => {
      const res = await fetch(`/api/todos?page=${pageParam}&pageSize=${PAGE_SIZE}`)
      return res.json()
    },
    getNextPageParam: (lastPage, allPages) => {
      return lastPage.hasMore ? allPages.length + 1 : undefined
    },
  })

  if (isLoading) return <Loading />
  if (isError) return <Error message={error.message} />

  const todos = data?.pages.flatMap(page => page.items) ?? []

  return (
    <div>
      {todos.map(todo => <TodoItem key={todo.id} todo={todo} />)}
      {hasNextPage && (
        <button onClick={() => fetchNextPage()} disabled={isFetchingNextPage}>
          {isFetchingNextPage ? 'Loading...' : 'Load more'}
        </button>
      )}
    </div>
  )
}

After: alova `usePagination`

import { usePagination } from 'alova/client'

function TodoList() {
  const {
    loading, data, page,
    pageSize, total,
    nextPage, prevPage,
  } = usePagination(
    (page) => alova.Get('/api/todos', { params: { page, pageSize: 10 } }),
    { total: res => res.total }
  )

  if (loading) return <Loading />

  return (
    <div>
      {data.map(todo => <TodoItem key={todo.id} todo={todo} />)}
      <Pagination
        page={page} total={total}
        onNext={nextPage} onPrev={prevPage}
      />
    </div>
  )
}

3 lines of core logic. page, pageSize, total, navigation, loading state — all built in. No useInfiniteQuery, no manual page state, no flatMap.

5 scenarios, side by side

1. Form submission + draft persistence

TanStack Query: You get useMutation for submission. Everything else — form state, localStorage draft, sync logic — is on you.

const mutation = useMutation({
  mutationFn: (data) => api.submitForm(data),
})
const [formData, setFormData] = useState({})
const [draft, setDraft] = useState(() => {
  return JSON.parse(localStorage.getItem('formDraft') || '{}')
})
useEffect(() => {
  localStorage.setItem('formDraft', JSON.stringify(formData))
}, [formData])
const handleSubmit = () => mutation.mutate(formData)

alova: One store: true flag = automatic draft persistence.

const {
  form, loading, sendForm,
  updateForm, reset,
} = useForm((formData) => alova.Post('/api/submit', formData), {
  initialForm: {},
  store: true,  // auto-draft to localStorage
})
const handleSubmit = () => sendForm()

2. Real-time SSE notifications

TanStack Query doesn't support SSE out of the box. You need a third-party library plus manual connection/reconnection logic.

alova has built-in useSSE:

const { data, readyState } = useSSE(
  alova.Get('/api/notifications', { /* SSE config */ })
)

readyState automatically reflects connection status (CONNECTING/OPEN/CLOSED). data is a reactive stream.

3. Auto-polling + focus refetch + throttling

Both libraries support polling and focus refetch. But alova's throttle parameter controls the minimum interval for both polling and focus refetch — no frantic re-fetching when the user keeps tab-switching.

useAutoRequest(alova.Get('/api/todos'), {
  throttle: 3000,    // 3s throttle
  enablePoll: true,  // polling on
  enableFocus: true, // focus refetch on
})

4. Server-side retry + rate limiting

TanStack Query is client-only. Its retry option only works in the browser.

alova's retry and RateLimiter work in Node.js, Bun, and Deno — and RateLimiter even supports Redis for distributed rate limiting across processes.

import { retry, RateLimiter } from 'alova/server'

// Server-side retry with exponential backoff
const result = await retry(
  alovaInstance.Post('/api/order', orderData),
  { retry: 3, backoff: { start: 1000, multiplier: 2 } }
).send()

// Distributed rate limiting
const limiter = new RateLimiter({
  points: 10,     // 10 requests
  duration: 1,    // per second
})
const result = await limiter.limit(
  alovaInstance.Get('/api/external')
).send()

This is a category of functionality TanStack Query simply cannot provide.

5. Cross-framework consistency

TanStack Query has different APIs per framework (@tanstack/react-query, @tanstack/vue-query, @tanstack/svelte-query).

alova uses the same API everywhere:

// React
const { data } = useRequest(alova.Get('/api/todos'))
// Vue — same API
const { data } = useRequest(alova.Get('/api/todos'))
// Svelte — same API
const { data } = useRequest(alova.Get('/api/todos'))
// Mini-programs (UniApp/Taro) — same API
const { data } = useRequest(alova.Get('/api/todos'))
// Node.js backend — just await
const data = await alova.Get('/api/todos')

Different imports, identical API. One mental model for every environment.

By the numbers

Scenario	TanStack Query	alova	Reduction
Paginated list	~50 LOC	3 LOC	94%
Form + draft	~35 LOC	3 LOC	91%
SSE notifications	~30 LOC (3rd party)	1 LOC	97%
Auto-polling	~10 LOC	2 LOC	80%
Retry (server)	~8 LOC	1 LOC	87%
Total (5 scenarios)	~133 LOC	~10 LOC	92.5%

This isn't to say TanStack Query is bad — it's excellent at what it does (caching + state management). But its philosophy is "here are the tools, you build the solution."

alova takes a different approach: 20+ built-in request strategies for real-world scenarios. Pagination, forms, SSE, polling, retry, rate limiting — they're all ready to use, not ready to build.

When to choose what?

Simple CRUD + caching: TanStack Query is fine. No issues.
Complex mid-office / BFF projects: Multiple request patterns → alova's strategy-based approach saves significant time.
Cross-framework / cross-platform projects: alova's framework-agnostic design is a clear advantage.
Server-side request control: Retry, rate limiting, distributed locking → alova is the only choice.

⭐ GitHub: alovajs/alova

🌐 Site: alova.js.org

What do you think is the next evolution of request libraries? Drop a comment below.

30 months of open source: How I maintain the Next-Gen request tool

Scott Hu — Tue, 03 Sep 2024 09:13:46 +0000

Two years ago, I designed and developed a JavaScript request strategy library called alovajs. Since its promotion in April 2023, it has received acclaim from developers around the world and has garnered over 2700+ stars, including recognition from experts at major companies.

Currently, alova@3.x has been released, positioned as "the next-generation request tool for streamlined workflows."

I have been maintaining it without compensation for 30 months, and the version has reached 3.x. During this period, through continuous reflection, rejection, and rethinking, I aimed to achieve something that other request tools have not done, to become a tool that can truly help front-end development. I believe I have found a reliable direction.

That is, to create a "next-generation request tool for streamlined workflows", maximizing the assistance to front-end development in streamlining the API integration process.

Below is the exploration story of alovajs, which is also the story of an open-source project from its inception.

If you are interested in alovajs, I sincerely invite you to join the community and make progress together.

Join the Discord community

alovajs Originated from a Small Project, but Its Mission is to Sail the Ocean

One day in March 2022, due to certain circumstances, I conceived the idea of developing an App called "Con of goal." Inspired by some apps, I hoped that "Con of goal" could achieve delay-free data requests and submissions, that is, an immediate response mode, even under weak or no network conditions. However, after searching online and not finding a suitable solution, and similar optimistic update solutions not meeting the needs, my damn desire to share led me to decide to implement it in the form of a request library, which was the starting point of alovajs, but it didn't have a name at that time.

Designing alovajs

The beginning of a library is not design, not development, but clarifying the needs

pro Tips: It is strongly recommended that you first briefly understand the overview section of alovajs to better understand the following content.

At that time, there was no product positioning, just creating a JavaScript library to meet my own needs. I studied existing request libraries and listed the following needs:

Support for seamless data interaction mode, that is, under network disconnection, it can still be submitted without delay, without the user's perception
Designed according to the popular useHook of the time, making the interface more user-friendly
A set of code supports multiple frameworks such as Vue, React, etc., and JavaScript operating environments such as browsers, React Native, UniApp, and Taro, etc.
Consistent usage in multiple JavaScript environments
Considering the caching function of react-query is very good, this should also be added
Due to the influence and simplicity of axios, make alovajs easy to get started with, and the design should be similar to axios

Then, based on the needs, the library's API was designed.

For needs 1, it was the starting point for me to do alovajs, but it was not simple. The design at the time was to add a silent parameter in the useHook configuration, which could immediately respond to the success callback, but it was later proven to be problematic and redesigned, which is now the seamless data interaction strategy

For needs 2, three core useHooks were designed: useRequest, useWatcher, and useFetcher. This is very familiar to everyone, such as ahooks' useRequest, vueuse's useAsyncState, react-query, and swr, needless to say, it is indeed very convenient.
Since the useHook design is used, different frameworks will have different state management, but I don't want to create a JavaScript library for each framework like react-query. Therefore, for needs 3, the specifications for stateHook adapters, request adapters, and storage adapters were designed, and different adapters can be written according to the specifications, separating the framework environment and runtime environment-related logic into separate modules.
For needs 4, the method instance proxy pattern was designed, and the method instance proxy calls the hook functions of different adapters, so that even if you develop any application, you can get started with alovajs without any unfamiliarity, and it can also be seamlessly transplanted.
For needs 5, similar JavaScript libraries implement caching in the form of custom keys, but my idea is to focus on request information. The common scenario is that when requesting the same interface with the same request method and parameters, it is necessary to hit the response data of the last time. Why don't we use these request information as caching keys? Therefore, alovajs has designed an automatic caching mechanism, which is enabled by default on GET requests.
For needs 6, refer to and learn from axios.

These designs have indeed been proven over time. alovajs has perfectly compatible with Vue, React, Svelte frameworks through the adapter method, and can also run in various JavaScript environments such as browsers, React Native, UniApp, and Taro, while maintaining a consistent usage method, which has given me a glimmer of hope.

In the following months, although alovajs was released, it has not been promoted. On the one hand, it is because I used it in the "Con of goal" project. Although it has been tempered and improved in this project, it is still very incomplete, and the positioning is not clear. The initial version introduction is like this.

Later, the "Con of goal" project was aborted, but alovajs is still persisting.

alovajs' Direction Exploration

With the obsession of once being an Internet product manager, I still hope to make alovajs a differentiated product. I often ask myself, what is the difference between alovajs and other request libraries? Why should users use alovajs? It is indeed different from other libraries in design, which is not a question that can be answered immediately. Later, I tried to position the direction of the request library as a "lightweight request library" and a "multi-end unified request library", but they were all denied by myself, because these cannot bring substantial help to developers, and they cannot be called advantages.

In September 2022, an opportunity made me discover the excellent request library based on Vue, vue-request. Its usePagination and useLoadMore immediately inspired me. This form of pagination implementation made me realize that this is also what I want. At the same time, it made me realize the power of useHook. I can divide the module according to the request scenario, use different useHooks for different scenarios, and the previously implemented seamless data interaction is actually one of the scenarios. If this is the direction, developers can choose different useHooks according to different request scenarios, which not only improves development efficiency and reduces coding complexity, but also prevents junior front-end from writing inefficient code, and can make better use of the core features of alovajs to achieve better performance and less server pressure. request features, so far, the "lightweight request strategy library" was chosen by me.

Then, in order to guide the future design direction of alovajs, I also refined and abstracted the request scenario model (RSM) of alovajs, mainly divided into the following four processes:

Request timing -> Request behavior -> Request event -> Response processing

Let's do it, I started to reconstruct alovajs 2.0 according to this positioning, separated the seamless data interaction function from 1.0, and designed a middleware mechanism to adapt to the development of more request scenario strategy useHooks, studied and developed the pagination strategy and seamless data interaction strategy.

The pagination strategy of alovajs is what I think is the most useful usePagination. It uses the caching function of alovajs to achieve pre-loading of front and back page data, pagination data search, request-level debouncing, and provides automated management of new editing and deletion functions, as well as refreshing the data of a specified page code without resetting.
The seamless data interaction strategy took me 4 months, constantly encountering dead ends, and constantly redesigning the result. It has achieved a strategy that allows users to interact with data without delay even in weak or disconnected network environments, and it can also more stably ensure the success of the request. I designed a virtual data thing, which can be used as a placeholder for response data before the response, making users feel that it is an immediate response, and then replace the virtual data with real data after the response is successful. According to the current exploration results, its usage scenarios can be editor-like applications, system setting modules, and some simpler lists.

Later, request strategy modules such as useForm, useAutoRequest, and useSSE were also added, but this is far from enough.

The idea of the Next-Generation Request Tool

On May 13, 2023, I received such an issue on github

At first, I didn't pay much attention to this issue, just simply understood the function of automatically generating request code for openAPI, and thought it was very good, but due to limited energy, I didn't think deeply about it, and I hadn't been thinking about the direction of alovajs at that time. But recently, I would occasionally think about the direction of alovajs, and this issue that is still open has always come to my mind, and then quietly changed the label of this issue from "feature-request" to "feature-request:confirmed".

At the same time, this issue made me realize that alovajs can also narrow the collaboration distance between front-end and back-end, and further simplify the front-end development workflow. This is the development direction I set for alovajs 3.0:

alovajs will help developers simplify the API integration workflow to the greatest extent, you only need to specify which API to use (this is also the result of thinking for 3 months)

My specific plan is as follows:

The steps 1, 2, 3, 4, 6 in the above figure are solved by automatically generating API code, but our generation plan will go further compared to tools like openapi-generator. It will automatically generate complete ts type, complete description request functions, whether it is a js project or a ts project, there is no need to introduce, let developers call as convenient as directly calling location.reload, and the request function can directly see the complete description and request parameter type prompts.
Since the automatically generated request functions have complete descriptions and type prompts, the vscode plugin completes the interactive way to quickly retrieve the required APIs, and you no longer need to refer to the API documentation.
Solve the problem of the front-end and back-end collaboration gap, and any changes in the interface can be automatically notified to the front-end. If there are changes found during the project construction, an error will be thrown to stop the construction. If it is a ts project, an error will also be thrown during compilation, and the change records can also be viewed through the vscode plugin.

Here is the demo video of vscode extension.

How to solve step 6 "write complex request logic"? Of course, it is to use the request strategy module, which has the characteristics of high performance and scene-based, and users can use a very small amount of code to implement various scene request functions.

In March 2024, the development plan for alova@3.0 was formulated, and it took 4 months to restructure almost the entire project with core member MeetinaXD, and there are many optimizations:

The underlying architecture was redesigned, and a set of hooks can be used simultaneously in Vue, React, Svelte, and even in the Vue options style.
The available range has been increased to the server side. You can use alova in server-side frameworks such as express, koa, and nestjs, and new server-side request strategy server hooks have been added.
10 configurations in alova@2.x were deprecated, and 9 designs were optimized.

In addition, the most important part of 3.0, the vscode plugin, which is in charge of our core member czlin, is also available, and it has basically achieved the goals we set at the beginning.

So far, alova@3.0 has passed the beta period and can be stably used in the production environment.

Only by continuous exploration can we become better

At that time, an article that was criticized, It's time to replace your axios made it to the hot search.

It was indeed not that good when it was just launched, but I know that every product is not achieved overnight, and it needs time to precipitate.

The Apple 1 computer didn't even have a case at the beginning

The development journey of Vue is also a process of continuous exploration and progress

I am just moved by such a product journey, and persisting in doing one thing is the easiest way to succeed. Good products need to be tested for several years, let alone alovajs, which has only been around for about 1.5 years, and has only been contacted by some people for 8 months. During this period, it has also been exploring better solutions and moving forward step by step.

alovajs initially designed useHooks including useRequest, useWatcher, useEffectWatcher, useManual, useController, and then gradually reduced to only three core hooks: useRequest, useWatcher, and useFetcher.

Commit address

In the design of parallel requests, whether to implement a form similar to Promise.all, or the current form of binding to the onSuccess function, I have been entangled in several versions, changed back and forth, and the following is the design of the abandoned responder of that year.

Commit record not found

In order to be compatible with asynchronous caching schemes such as IndexedDB, I initially tried to design the storage adapter as an asynchronous function, but it would bring a series of problems, and then tried to implement the event mechanism through StorageConnector, which is still not perfect enough, and finally to the current custom localCache asynchronous function mechanism.

Commit address

I also thank friends who have supported and contributed to alovajs. The following are a few screenshots, and there are many contributions that are not included.

And continuously supplement the details of the document and improve the best practices, boldly try the cache version plan for the cache recovery mode, and in order to provide complete ts type prompts for alovajs, try to use automatic type inference to reduce the trouble of developers defining types, and indeed spend a lot of effort to optimize and compatible with different UI frameworks, etc.

Among them, the document has been greatly changed two to three times. I am grateful to @Orange Peel for providing the first document modification opinion, and @Well for providing the second document modification opinion, and then our document has such a reputation.

@green tree helped me open up new ideas for alova.

Many things are no longer clear, and the records on npmjs tell me that 146 versions have been released.

There are also many people on github who have raised bugs, and I have also responded and fixed them in the first time. I am really very grateful. If I can't judge the problem immediately, I will also reproduce it on codesandbox, and use this demo as a bridge for communication with users.

The END

Thank you very much for your reading🤗, no matter how difficult it is, the road still needs to continue.

If you recognize alovajs, please go to Github to give it a star.

If you want to understand alova, you can visit the official website, where you can find more detailed documentation and example code to help you better understand and use this tool.

If you have any questions, you can join the following group chats for consultation, or you can also post Discussions in the github repository. If you encounter problems, please submit them in github issues, and we will solve them in the fastest time.

Join the Discord community

We also welcome you to contribute your strength, please go to the Contribution Guide.

react-query swrjs alova In-Depth Comparison

Scott Hu — Sat, 31 Aug 2024 08:03:29 +0000

As our projects become increasingly complex, users are demanding higher speed and better user experiences. Relying solely on traditional request libraries like Axios or Fetch to handle data requests often results in a lot of redundant boilerplate code, which has long been criticized. This is where enhanced request libraries come into play.

Some of you might be wondering, "What exactly is an enhanced request library?" An enhanced request library typically builds on top of traditional request libraries and integrates deeply with UI frameworks like React and Vue through hooks. It also provides additional performance optimization features, such as response caching, to help reduce boilerplate code and improve request performance.

Currently, some of the most popular enhanced request libraries include @tanstack/react-query, swr, and the rising star alova. Each has its unique features. Here, we'll take a deep dive into comparing them to help you determine which one best suits your project's needs. That way, when a new project requirement arises, you'll know exactly which tool to choose.

Quick channel for comparison tools

Let's start right now and compare them from the following 8 perspectives.

Product positioning and features
hooks
Framework support
Server support
Request method
Cache strategy
API automation solution
Performance

Comparison of Positioning and Features

First, let's discuss their different positioning.

@tanstack/react-query primarily focuses on managing asynchronous state. Its strength lies in helping you handle data fetching, caching, and synchronization. When you need data, it fetches it for you; when the data becomes stale, it updates it.

swr also focuses on asynchronous state management, using lightweight hooks to simplify data fetching.

alova provides a comprehensive request solution, mainly to help developers raise API integration efficiency. It reduces the number of steps for developers to use API from 7 to just 1, helping developers reduce a lot of API maintenance time.

Different positioning means these libraries have different design considerations. react-query and swr focus mainly on the hooks they provide and cache management functions. In contrast, alova optimizes API consumption efficiency by taking a more holistic approach to the request strategy. It not only offers hooks but also includes hook middleware, global seamless refresh interceptors, and other features referred to as request strategies. It also provides automatic API generation and search extension plugins. Because of this, I believe alova addresses API-related challenges in multiple aspects.

Let's look at a comparative example in React.

react-query



import { useQuery } from '@tanstack/react-query';

const fetchUsers = async () => fetch('https://api.example.com/users')
    .then(res => res.json());
function UserList() {
  const { data: users, isLoading, error } = useQuery('users', fetchUsers);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>An error occurred: {error.message}</div>;

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

export default UserList;

swr



import useSWR from 'swr';

const fetcher = url => fetch(url)
    .then(res => res.json());

function UserList() {
  const { data: users, error } = useSWR('https://api.example.com/users', fetcher);

  if (!users) return <div>Loading...</div>;
  if (error) return <div>An error occurred: {error.message}</div>;

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

export default UserList;

alova



import { createAlova, useRequest } from 'alova';
import adapterFetch from 'alova/fetch';
import ReactHook from 'alova/react';

const alovaInstance = createAlova({
  baseURL: 'https://api.example.com',
  statesHook: ReactHook,
  requestAdapter: adapterFetch(),
});

function UserList() {
  const methodInstance = alovaInstance.Get('/users');
  const { loading, data: users, error } = useRequest(methodInstance);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>An error occurred: {error.message}</div>;

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

export default UserList;

You can see. react-queryandswrsend requests directly with asynchronous functions, whilealovaneeds to create a request instance in advance, which defines how to send requests using the fetch adapter under react. In addition, adapters such asxmlhttprequestandaxios are also provided. These are all due to their positioning-dominated design concepts, and these differences will be reflected in the following comparisons.

Comparison of hooks

Number of hooks

@tanstack/react-query provides hooks such as useQuery, useMutation, and useInfiniteQuery.
swr mainly provides hooks such as useSWR and useSWRInfinite.
alova provides a total of 15+ request strategies in different request scenarios, including useRequest, useWatcher, usePagination, useFetcher, useForm, etc.

hook actions

One of the features of alova's hooks is that its scenario-based hooks also provide a wealth of actions, which allow developers to more finely control data operations and quickly implement the comprehensive functionality of different complex requests, which is not available in react-query and swr. For example, the following is actions for paging request.



import { usePagination, useForm } from "alova/client";

// Pagination request example
const {
  loading,
  data,
  page,
  pageSize,
  pageCount,
  total,
  insert,
  remove,
  replace,
  refresh,
  reload,
} = usePagination((page, pageSize) => getUserList({ page, pageSize }), {
  initialPage: 1,
  initialPageSize: 10,
});

// Use actions
const handleAddUser = (newUser) => {
  insert(newUser);
};
const handleRemoveUser = (userId) => {
  remove((user) => user.id === userId);
};

hooks middleware support

alova and swr's hooks support middleware, allowing more fine-grained customization during the request process. But react-query does not support it.

swr



function myMiddleware (useSWRNext) {
return (key, fetcher, config) => {
// Before hook runs...

// Process the next middleware, or the `useSWR` hook if this is the last one.
const swr = useSWRNext(key, fetcher, config)

// After the hook runs...
return swr
}
}

<SWRConfig value={{ use: [myMiddleware] }}>

// Or...

useSWR(key, fetcher, { use: [myMiddleware] })

alova



import { useRequest } from "alova/client";

// Define a middleware
const loggingMiddleware = async (context, next) => {
  console.log("Request started:", context.config);
  const response = await next();
  console.log("Request ended:", response);
};

// Use middleware in hook
const { loading, data } = useRequest(getUserList, {
  middleware: loggingMiddleware,
});

Framework support

Client

@tanstack/react-query supports mainstream UI frameworks in the form of independent packages, although it was originally designed for React.

react: @tanstack/react-query
vue: @tanstack/vue-query
svelte: @tanstack/svelte-query
angular: @tanstack/angular-query
solid: @tanstack/solid-query

swr only supports react.
alova supports frameworks such as react/vue/svelte with a single package + UI framework adapter, unifying the user experience under each UI framework.

SSR

All three support mainstream SSR frameworks.

Server support

@tanstack/react-query and swr mainly provide clienthooks for client applications. Although they can be used in a server-side rendering (SSR) environment, they cannot be used directly in a non-SSR server-side environment, but they do not provide APIs used in pure server-side environments (such as Express or Koa route handlers).

In contrast, alova not only fully supports server-side programs, but also provides server-side request strategies for the server-side environment. They are called server hooks, which makes it easier and more flexible to control requests on the server side.

The following is an example of sending a verification code with retry:



const { retry, sendCaptcha } = require("alova/server");

app.get("/api/captcha/send", async (req, res) => {
  const email = req.params.email;
  // Create a method instance for sending a verification code
  const captchaMethod = alovaInstance.Post("/api/captcha", {
    email,
    content: "captcha content",
  });

  // Use retry hook to wrap captchaMethod
  const retringMethod = retry(captchaMethod, {
    retry: 3,
    backoff: {
      delay: 2000,
    },
  });
  // Use sendCaptcha hook to wrap retringMethod, and send the request and get the response result through await
  const result = await sendCaptcha(retringMethod, {
    key: email,
  });
});

Request method

@tanstack/react-query and swr provide asynchronous functions to receive request data. Users need to directly use axios or fetch third-party request libraries to obtain data and provide it to @tanstack/react-query and swr. This gives all control of the request to the user, and even simulates the request in the asynchronous function.



const fetchUsers = async () =>
  new Promise((resolve) => {
    setTimeout(() => {
      resolve({ data: "your data" });
    }, 1000);
  });
const { data: users, isLoading, error } = useQuery("users", fetchUsers);

But alova uses Method as a proxy object, which has the following advantages for me:

Provides a unified request method. Users do not need to care about what method is used for request except setting the request adapter.
It has various uses. Users can use Method to send requests directly like axios, and can also directly pass it into hooks to control requests.



// Direct request
const res = await alvoaInstance.Get("/users");

// Pass in request in useRequest
const { loading, data, error } = useRequest(alvoaInstance.Get("/users"));

For example, using XMLHttpRequest request can also get a complete and unified experience, including global interceptors. Alova provides XMLHttpRequest adapter, but it needs to be encapsulated in @tanstack/react-query and swr.
Easy to port to other projects, just change the request interceptor globally.

Cache strategy

@tanstack/react-query

Fine cache control: @tanstack/react-query allows to configure staleTime and cacheTime to determine the cache duration and expiration time of data.
Automatic refresh and invalidation: Configure automatic refresh of data under certain conditions through options such as refetchOnWindowFocus and refetchOnReconnect.
Cache data persistence: Implement persistent storage of client cache data through the persistQueryClient plugin.
Cache debugging tool: Provides ReactQueryDevtools debugging tool for observing and processing data requests and cache status.

swr

Custom global cache: SWR uses a global cache to share data, and allows customizing how to store cache through the provider option of SWRConfig.
Modify cache data: Provides mutate function to modify the cache, including clearing all cached data or updating specific cache items.
Cache debugging tool: View and debug through browser extensions.

alova

Multi-level cache: Supports L1 and L2 multi-level cache, and can restore data from persistent storage after the memory cache is invalidated to adapt to different usage scenarios.
Fine cache control: Allows you to set different expiration times for different levels of cache, providing more flexible cache management.
Automatic cache invalidation: Automatically invalidate the corresponding cache by specifying the relationship between APIs, reducing the trouble of manual invalidation.
Flexible cache storage: You can use any cache storage to store data, such as localStorage, sessionStorage, indexedDB on the client, AsyncStorage under react-native, and @alova/psc shared by multiple processes on the server, or even redis storage shared by clusters.

API Automation Solution

Since @tanstack/react-query and swr give all control of the request to the user, the API automation solution is provided by third-party request tools. For example, axios and fetch can automatically generate request codes through openapi-generator or @openapitools/openapi-generator-cli.

Alova provides a more advanced openAPI solution. , including the following:

Generate API call code, TypeScript type and detailed API documentation for each API at the same time, so that you can enjoy complete API type hints even in JavaScript projects, which are not available in openapi-generator and @openapitools/openapi-generator-cli.
A brand new API integration experience. In the past, when the backend developer delivered the API to you, you needed to open the intermediate API document to query and copy key information to your project. You needed to constantly switch between the API document and the editor in the middle, but now, Alova's development tools can eliminate the intermediate API document for you, shortening the collaboration distance between the front and back ends like a wormhole. Through it, you can quickly find the required API in the editor and display the complete documentation of this API, and quickly complete parameter transfer by referring to the API parameter table.

Update the API regularly and actively notify the front-end development, no longer relying on the notification of the server-side developer.

Performance

Dependency collection

Dependency collection refers to the automatic tracking of the status of component dependencies within hooks. When the status of the dependency changes, it will trigger the re-rendering of the view. This is more of a way to reduce the rendering of react components.

swr and alova both support dependency collection, while @tanstack/react-query does not.

Alova's unique performance features

Request sharing

Request sharing means that when multiple identical requests are issued at the same time, only one request will be actually issued, and the response data will be shared with these requests. It can not only improve the fluency of the application, but also reduce the pressure on the server.

@tanstack/react-query and swr are not supported, alova is supported on both the client and the server.

hooks performance optimization

Compared with @tanstack/react-query and swr hooks, one feature of alova's scenario-based hooks is that it can optimize performance for specific scenarios, for example:

usePagination can automatically pre-fetch the list data of the previous and next pages, so that users do not need to wait when turning pages (turning pages in seconds)
useForm provides a form draft, and unsubmitted data will not be deleted even if it is refreshed

Default GET cache

Since alova's cache key is automatically calculated through the request information of the method instance, by default, alova's GET has a 5-minute cache, and there is no need to repeat the request when multiple requests for duplicate data are made.

Conclusion

After an in-depth discussion, we have a more comprehensive understanding of the three request enhancement libraries alova, @tanstack/react-query and swr. Each library has its own unique advantages and applicable scenarios. Which library to choose ultimately depends on your project requirements, the team's technology stack, and considerations of performance, ease of use, and flexibility.

swr is known for its simplicity and ease of use. If you are looking for a lightweight and easy-to-use solution, or your project focuses on fast rendering and minimizing server requests, srw will be an ideal choice.
For applications that require powerful state management and caching capabilities, @tanstack/react-query is a good choice.
If you don't want to spend more time on API use, want to find a unified request solution, or are sending requests in Express or koa, alova may be more suitable for your needs.

There is no best library, only the one that best suits your project. Take the time to evaluate and compare different tools, and finally choose the one that can help you and your team work more efficiently and happily.

I hope this article can help you better understand the characteristics of these three request enhancement libraries and make wise choices in actual projects.

Bye everyone!!!

3 months later, I optimized request code generation to the extreme

Scott Hu — Fri, 28 Jun 2024 04:24:53 +0000

Have you ever heard of the automatic request code generation solution? Yes, that's right, it's generated by the openapi specification, and I always feel that something is missing.

After 3 months of research, I have simplified the front-end and back-end collaboration process into one step!

Usually, the front-end and back-end collaboration is a tedious task. Usually we may have such a process:

The back-end notifies the front-end "xxx interface is ready"
First look through the api document to find the newly added api
Go back to your own code and define all new api call functions
If you use TS, you have to add type definitions manually
In different pages, select the corresponding api call function
Introduce the call function
Write complex call logic, such as paging and controlling the page number parameter

We have removed all the 123467 above, and even eliminated the intermediate api document link, allowing you to check and call the api in the editor, which may change your future development method.

Let me explain it in detail.

Automatic generation

Automatically generating API call code according to the openapi specification should be a commonplace, and my solution is to use the VSCode plug-in. Whether you use ESModule, CommonJS or TypeScript, click the generate button in the lower right corner of the editor, it will automatically generate the corresponding standard interface call code and the corresponding response type according to the project type. Whether in js or ts projects, you can experience the complete code prompt function.

dev-to-uploads.s3.amazonaws.com

Generated code Contains the following content:

apiDefinitions.js is used to record the generated api path and request method.
createApis.js uses proxy to dynamically create call functions based on apiDefinitions.js, which can reduce a lot of template code.
globals.d.ts provides complete code prompt function.
index.js is used for user-defined configuration.

This cuts off step 34 in the process.

Then we can also set a timer to check the update status of the openapi file. If there is an update, we will immediately remind you to ensure that you always use the latest api definition. This saves the backend partner from notifying you of api updates, and eliminates step 1 in the process.

Now the process is as follows:

~~The backend notifies the frontend "xxx interface is ready"~~
First look through the api document to find the newly added api
~~Go back to your own code and define all new api call functions~~
~~If you use TS, you have to add type definitions manually~~
In different pages, select the corresponding api call function
Introduce the call function
Write complex call logic, such as paging and controlling the number of pages

Check and use the API in the editor

In order to eliminate step 2, we really racked our brains, so let's just move the api document to the editor and copy the parameters according to the description when you use the interface.

The following is a demonstration of a js project without any additional configuration.

Access the interface through the global Apis, reference src/api/index in the entry file, and then you can directly access it everywhere, which eliminates step 7 again, and the editor's smart prompt displays all the information of the current api.

You can also see the prompts and descriptions of the parameters when filling in the parameters.

The response data prompt is as follows.

Find API through path

What is this? I don't know what the specific reference name is? It doesn't matter, you can also find it by using the API call path:

Find the API by description

Really can't remember anything? Then search using the keywords in the API description:

At this point, steps 2 and 6 are also done:

~~The backend notifies the frontend that "xxx interface is ready"~~
~~First look through the api document to find the newly added api~~
~~Go back to your own code and define all new api call functions~~
~~If you use TS, you have to add type definitions manually~~
In different pages, select the corresponding api call function
~~Introduce calling function~~
Write complex calling logic, for example, paging also needs to control the number of pages

Request strategy modules

How to solve step 7? Of course, encapsulate the calling logic according to different usage scenarios. Although there seem to be many scenarios, let's encapsulate the commonly used ones first, so there are the following encapsulations, which we call "request strategy module" because it is not only encapsulation, but also many performance optimizations.

Here are some simple examples, such as paging request:

const { loading, error, data, page, pageSize, total } = usePagination(
  (page, size) =>
    alova.Get("/api/user/list", {
      params: { page, size },
    })
);

Form submission:

const {
  // Submission status
  loading: submiting,
  // Responsive form data
  form,
  // Submission data function
  send: submit,
} = useForm((formData) => formSubmit(formData), {
  // Initialize form data
  initialForm: {
    name: "",
    cls: "1",
  },
});

Monitor request:

const { loading, data } = useWatcher(
  // State change will trigger this function once
  () => filterTodoList(userId.value),

  // Array of monitored states
  [userId]
);

Now, it is finally simplified to only one step.

~~The backend notifies the frontend that "xxx interface is ready"~~
~~First look through the api document to find the newly added api~~
~~Go back to your own code and define the call function for all new apis~~
~~If you use TS, you have to add type definitions manually~~
In different pages, select the corresponding api call function
~~Introduce the call function~~
~~Write complex call logic, such as paging and controlling the number of pages~~

The last easter eggs

At this point, I believe you have already felt the convenience of this plug-in, right? This is actually a VSCode plug-in tailored for alova!

Our easter egg is that alova has finally ushered in a major upgrade to 3.0, redesigning the underlying architecture and comprehensively refactoring. Now it can be used completely in the client and server. In addition, in order to make it easier to use, this upgrade has abandoned 10 configurations and 9 optimizations. If you think alova is good, please star us on Github.

Visit the official website of alovajs for more details: alovajs official website.

And this plug-in is not just an ordinary development tool, but it maximizes the convenience of alova. Through this plug-in, we have brought the user experience of alova to a whole new level, truly realizing the goal of "as simple as calling a local function".

However, our team is now conducting the final optimization and testing of this plug-in, which will be released in the near future. Good things are always worth waiting for. You are also welcome to tell us your thoughts, complaints or suggestions in the comment area.

If you are an alova user, or are interested in experiencing our project, you can join our WeChat group to get the latest progress at the first time, and you can also communicate directly with the development team and put forward your ideas and suggestions.

Join the Discord

After joining the communication community, you will get:

The latest news about plugins and alova
Exchange usage experience with other developers
Make suggestions or feedback directly to the development team
Possible internal testing opportunities

If you have any questions, you can join the following group chat for consultation, or post Discussions in the github repository. If you encounter any problems, please submit them in github issues, and we will solve them as soon as possible.

You are also welcome to contribute. Please go to the Contribution Guide

The next generation request library alova has received a major upgrade, making it easier to use and higher in performance.

Scott Hu — Fri, 10 May 2024 03:09:26 +0000

hello!

Maybe you have also heard of alova, a lightweight request library, which can help you implement complex data requests at a lower cost, saving developers energy and time.

If you need to learn about alova, you can visit the official website, where you can find more detailed documentation and sample code to help you better understand and use this tool.

It has been a year since the release of alova2.0. During this period, it has received a lot of praise. Of course, it has also received a lot of feedback for improvements, which has made alova continue to mature and improve. I am very grateful to everyone who has contributed to alova, and I also know it. There are many redundancies and flaws in the design.

Now, in order to better serve you, it is time to upgrade to 3.0. The purpose of this upgrade mainly focuses on the following goals:

Adjust alova structure and expand application scope
Simplify usage, discard unnecessary APIs, and adjust defective designs.
Redesign some modules to improve performance

Before looking at the specific 3.0 adjustments, let us review what exactly alova is going to do and where it is going.

Pain points of network requests

In enterprise-level projects involving multi-person collaboration, the cost of Client-Server interaction is relatively high.

High cost of front-end and back-end collaboration:
1. Depends on backend notification: API updates require active notification from the backend
2. API document dependence: The front end needs to consult the API document to obtain information.
3. API code writing: The front-end manually writes the interface code according to the API document.
4. Lack of response data type: API response data does not have type hints by default, which increases the cost of data usage.
5. Increase in bug rate: API changes may lead to an increase in the bug rate of the project.
Complex data interaction logic: Front-end requests are often not that simple. You need to consider when to send requests, when not to send requests, how to process response data, etc. according to different scenarios to meet the performance and performance improvement of the project. This will result in increased developer time costs and code maintenance costs.

solution

IDE plug-in (vscode/webStorm): Solve the problem of front-end and back-end collaboration (specific solutions can be viewed in the Feishu document below)
1. Automatically generate request codes and response data types
2. Embed the api document into the code, you can directly query and insert the API interface in the code
3. Update API information regularly and proactively notify front-end development
4. Interface update records to prevent changes from causing bugs
Request Strategy: Select the corresponding request strategy and implement complex data interaction logic in one line of code.

alova goals

Don't spend time on the small matter of requesting, leave it to alova, it will save you most of the work in requesting, you only need to specify which API to use and what strategy to execute the request. .

alova@3.0 update plan

Release Notes

Before the official version 3.0 is released, we always welcome your feedback. You are welcome to comment in the article or submit your valuable opinions on WeChat from any angle such as usage scenarios and design issues.

The specific update content, progress, and IDE plug-in design can be viewed in alova product white paper and 3.0 update overview.

Join the Discord community to participate in communication

Find core partner people

alovajs has so far achieved certain feasibility verification. In order to speed up its development, it is now necessary to invite two friends who agree with alovajs to join the core team (one has been confirmed) to be responsible for the core work of alovajs. This may allow you to obtain huge benefits. Friends who are willing to learn more see Become a Core Member.

Quickly implement senseless refresh token

Scott Hu — Fri, 19 Jan 2024 05:43:38 +0000

Some time ago, Alova users frequently received feedback on how to implement a senseless token refresh function like Axios. This is indeed troublesome, and I believe everyone has a deep understanding of it.

It really depresses me to have to repeat it every time. So out of anger, I decided to write a universal token authentication module so that alova users would no longer have to worry about this matter.

Using alova's Token authentication interceptor can perfectly solve the following problems for you:

Unify and maintain all codes for token identity authentication, including login, logout, token attachment, token refresh, etc.;
Supports verification of token expiration on the client and server, and refreshes the token without any warning;
Requests that rely on tokens automatically wait for the token refresh to complete before requesting;
Automatically release visitor requests that do not rely on tokens;

The only thing you have to do is configure the role type of the request interface, and then the rest will be automatically taken care of for you.

Some people may not know it. To give a brief introduction, alova is a request strategy library. Its usage is similar to axios, but you can implement complex requests such as request sharing, paging request, form submission, and breakpoint resume by simply configuring parameters. Etc., there is no need to write a lot of code, improve development efficiency, application performance, and reduce server pressure.

The Token identity authentication module is one of alova's request modules. It is completed through a global interceptor and provides client- and server-based identity authentication respectively.

Client-based identity authentication: means judging whether the token has expired from the client, such as the token expiration time obtained during login;
Server-based identity authentication: It indicates whether the token has expired based on the status returned from the server. For example, when status is 401, it means it has expired;

Next, let’s talk about server-based identity authentication as an example.

Install the dependencies first

#vue
npm install alova @alova/scene-vue --save
# react
npm install alova @alova/scene-react --save
#svelte
npm install alova @alova/scene-svelte --save

Implement nonsensical refresh Token on the server side

When the status returned by the server is that the token has expired (for example, 401), it means that the token needs to be refreshed. At this time, requests initiated during the refresh process will also be waiting.

const { onAuthRequired, onResponseRefreshToken } = createServerTokenAuthentication({
   refreshTokenOnSuccess: {
     // Triggered when responding, the response and method can be obtained, and a boolean is returned to indicate whether the token has expired.
     // When the server returns 401, it means the token has expired.
     isExpired: response => {
       return response.status === 401;
     },

     // Triggered when the token expires, trigger the refresh token in this function
     handler: async (response, method) => {
       const { token, refresh_token } = await refreshToken();
       localStorage.setItem('token', token);
       localStorage.setItem('refresh_token', refresh_token);
     }
   }
});

It will return two interceptor functions, which we can bind to alova's global request interceptor and response interceptor respectively.

import { createServerTokenAuthentication } from '@alova/scene-*';
import { createAlova } from 'alova';

const { onAuthRequired, onResponseRefreshToken } = createServerTokenAuthentication({
   // ...
});

const alovaInstance = createAlova({
   // ...
   beforeRequest: onAuthRequired(method => {
     // ...interceptor before original request
   }),
   responded: onResponseRefreshToken((response, method) => {
     //...original response success interceptor
     return response.json();
   })
});

Finally, in order to prevent the refreshToken request from being intercepted, it is necessary to identify authRole as refreshToken through metadata.

For more information about metadata, please go to method metadata.

export const refreshToken = () => {
   const method = alovaInstance.Get('/refresh_token');
   method.meta = {
     authRole: 'refreshToken'
   };
   return method;
};

In this way, a complete token silent refresh function is completed

Release visitor request

Some interfaces do not need to rely on token authentication. We call them "guest requests". At this time, we can set their metadata to authRole: null to bypass the front-end interception and allow them to send requests and receive responses smoothly.

export const requestTokenNotRequired = () => {
   const method = alovaInstance.Get('/token_not_required');
   method.meta = {
     authRole: null
   };
   return method;
};

End

In addition, the token authentication request module also provides functions based on client status verification (that is, the front end determines whether the token has expired), login interception, logout interception, etc., making the login authentication function simpler. Documentation of token authentication module is here.

If you have any questions, you can join the following group chat for consultation, or you can publish Discussions in github repository. If you encounter problems, please also post in github issues and we will solve it as soon as possible.

Join the Discord community to participate in communication

You are also welcome to contribute, please go to Contribution Guide.

Refresh token silently in alovajs

Scott Hu — Mon, 18 Dec 2023 06:14:59 +0000

alova is a lightweight request strategy library designed to simplify the management and use of interfaces. By simply configuring parameters, you can implement complex requests such as sharing requests, paging requests, form submissions, breakpoint resumption, etc., without writing a lot of code, improving development efficiency, application performance, and reducing server pressure.

When requesting, we often need to authorize login through token, and refresh the token through refresh_token when the token expires. Here we will discuss how to refresh the token without any sense through alova, that is, automatically refresh the token when the token is found to have expired. At the request initiation point It will not feel that the token has been refreshed.

At present, the token authentication module has been launched. It only requires simple configuration to achieve senseless token refresh. It is recommended to use it directly. View details->

The following are two ideas for implementing a senseless refresh token. Each idea implements the function of the token to wait for other requests during the refresh period.

Determine token expiration on the front end

This is used to determine whether the token has expired at the front end. This is usually used when the token expiration time is returned during login. The idea is to determine whether the token has expired in beforeRequest. If it has expired, refresh the token first and then continue to send the request. Its advantage is A response with an expired token will not be received, so there is no need to send repeated requests.

let token = '', refreshToken = '', tokenRefreshing = false, waitingList = [];
const alovaInstance = createAlova({
   // ...
   beforeRequest: async method => {
     if (getCache('token_expire_time') < Date.now() && method.meta?.authType !== 'refreshToken') { // token expires
       if (tokenRefreshing) {
         // If the token is being refreshed, wait for the refresh to complete before sending a request.
         console.log('Refreshing token, waiting for request');
         await new Promise(resolve => {
           waitingList.push(resolve);
         });
       }

       try {
         tokenRefreshing = true;
         const { refreshToken: newRefreshToken, token: newToken } = await tokenRefresh({ refreshToken });
         //Save the new token and refreshToken
         token = newToken;
         refreshToken = newRefreshToken;

         tokenRefreshing = false;
         // After refreshing the token, notify the requests in the waiting list
         waitingList.forEach(resolve => resolve());
         waitingList = [];
       } catch(error) {
         // If the refresh token fails, you can handle operations such as jumping to the login interface.
         // ...
       }
     }

     method.config.headers.Authorization = token;
   },
})

Here the tokenRefresh request method adds meta data ofauthType = 'refreshToken' as an identifier before the request can pass.

export const tokenRefresh = () => {
   const method = alovaInst.Get('/refresh-token', {
     localCache: null
   });
   method.meta = {
     authType: 'refreshToken'
   };
   return method;
}

Determine token expiration based on the status returned by the server.

This method is to determine whether the token has expired through the return status of the server. This is usually used when the token expiration time is not returned during login. The idea is to determine whether the token has expired by returning the status in responded.onSuccess. If it has expired, refresh the token. The advantage of sending the request again is that it is more accurate, but duplicate requests will also be sent.

let token = '', refreshToken = '';
let tokenRefreshing = false; // Refreshing token, let other requests wait first
let waitingList = [];
const alovaInst = createAlova({
   // ...
   beforeRequest: async ({ url, config, meta }) => {
     console.log(url, 'Requesting');
     // If the token is being refreshed, wait for the refresh to complete before sending a request.
     if (tokenRefreshing && meta?.authType !== 'refreshToken') {
       console.log('Refreshing token, waiting for request');
       await new Promise(resolve => {
         waitingList.push(resolve);
       });
     }
     config.headers.Authorization = token;
   },
   responded: async (response, method) => {
     if (response.status === 401) { // token expires
       console.log(method.url, 'Token expires, get token again');
       try {
           // This prevents requests to refresh the token multiple times, and intercepts and waits for requests sent before the token refresh is completed.
           if (tokenRefreshing) {
             console.log('Refreshing token, waiting for request');
             await new Promise(resolve => {
               waitingList.push(resolve);
             });
           })
         tokenRefreshing = true;
         const { token: newToken, refreshToken: newRefreshToken } = await refreshToken({ refreshToken });
         token = newToken;
         refreshToken = newRefreshToken;

         tokenRefreshing = false;
         waitingList.forEach(resolve => resolve());
         waitingList = [];
         console.log('New token has been obtained and saved', token, `Revisit ${method.url}`);

         // This is because the original interface is re-requested, and superposition with the previous request will result in repeated calls to transformData, so transformData needs to be left empty to remove one call.
         const methodTransformData = method.config.transformData;
         method.config.transformData = undefined;
         const dataResent = await method;
         method.config.transformData = methodTransformData;
         return dataResent;
       } catch(error) {
         // If the refresh token fails, you can handle operations such as jumping to the login interface.
         // ...
       }
     }
     return response.json();
   },
});

So far, Alova's two ideas for refreshing tokens have been implemented, and there is no sense of token refresh at the request initiation point.

If you want to learn more about the usage of alovajs, welcome to alova official website to learn. If you also like alovajs, please contribute a star in Github repository, which is very important to us.

If you think the article is helpful to you, please don't be stingy with your likes and comments. Tell me what you think of alovajs, or ask some questions. I will try my best to answer them. Your support is the biggest motivation for my creation! Hahahahahaha~

Welcome to join our community

Join the Discord community to participate in communication

You are also welcome to contribute, please go to Contribution Guide.

DEV Community: Scott Hu

From Axios to alova: how we cut 80 lines to 5

The Pattern: Paginated List in Two Ways

What Changed

Beyond Pagination

When to Use (And When Not To)

Summary

Stop writing useEffect for data fetching. Use Request Strategies instead.

Stop writing useEffect for data fetching. Use Request Strategies instead.

The Before: useEffect Hell

The After: Request Strategies with alova

What Are "Request Strategies"?

The Results

Getting Started

Hello Dev.to - Test Post

Hello Dev.to

文章标题23

文章标题

I replaced TanStack Query with alova and cut my code by 70%

I replaced TanStack Query with alova and cut my code by 70%

First shock: Pagination went from 50 lines to 3

Before: TanStack Query

After: alova usePagination

5 scenarios, side by side

1. Form submission + draft persistence

2. Real-time SSE notifications

3. Auto-polling + focus refetch + throttling

4. Server-side retry + rate limiting

5. Cross-framework consistency

By the numbers

When to choose what?

30 months of open source: How I maintain the Next-Gen request tool

alovajs Originated from a Small Project, but Its Mission is to Sail the Ocean

Designing alovajs

alovajs' Direction Exploration

The idea of the Next-Generation Request Tool

Only by continuous exploration can we become better

The END

react-query swrjs alova In-Depth Comparison

Comparison of Positioning and Features

react-query

swr

alova

Comparison of hooks

Number of hooks

hook actions

hooks middleware support

swr

alova

Framework support

Client

SSR

Server support

Request method

Cache strategy

@tanstack/react-query

swr

alova

API Automation Solution

Performance

Dependency collection

Alova's unique performance features

Request sharing

hooks performance optimization

Default GET cache

Conclusion

3 months later, I optimized request code generation to the extreme

Automatic generation

Check and use the API in the editor

Find API through path

Find the API by description

Request strategy modules

The last easter eggs

The next generation request library alova has received a major upgrade, making it easier to use and higher in performance.

Pain points of network requests

solution

alova goals

alova@3.0 update plan

Release Notes

Find core partner people

After: alova `usePagination`