Axios interceptors in Vue - Deep Dive

Overview - Axios interceptors

What is it?

Axios interceptors are functions that run before a request is sent or after a response is received when using Axios, a tool to make web requests. They let you change or check the request or response automatically without changing each call. This helps manage things like adding login tokens or handling errors in one place. Interceptors work behind the scenes to make your code cleaner and easier to maintain.

Why it matters

Without interceptors, you would have to repeat the same code to add headers or handle errors every time you make a web request. This repetition wastes time and can cause mistakes. Interceptors solve this by letting you write that code once and apply it everywhere automatically. This makes your app more reliable and easier to update, especially when dealing with many requests.

Where it fits

Before learning interceptors, you should understand how to make basic Axios requests in Vue and how promises work in JavaScript. After mastering interceptors, you can learn about advanced error handling, token refresh strategies, and global state management for authentication in Vue apps.

Mental Model

Core Idea

Axios interceptors are like automatic checkpoints that modify or check every request or response before it continues.

Think of it like...

Imagine a security guard at a building entrance who checks every visitor’s ID and sometimes adds a visitor badge before letting them in. Similarly, interceptors check and modify requests or responses automatically.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  Your Code    │──────▶│ Request       │──────▶│ Server        │
│ (makes call)  │       │ Interceptor   │       │ (response)    │
└───────────────┘       └───────────────┘       └───────────────┘
                              │                        ▲
                              ▼                        │
                       ┌───────────────┐       ┌───────────────┐
                       │ Response      │◀──────│ Server        │
                       │ Interceptor   │       │ (sends data)  │
                       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is Axios and basic requests

Concept: Learn what Axios is and how to make simple web requests.

Axios is a tool to send and receive data from servers using JavaScript. You can ask for data with axios.get('url') or send data with axios.post('url', data). These calls return promises that resolve when the server replies.

Result

You can fetch or send data to a server and get the response in your Vue app.

Understanding basic Axios requests is essential because interceptors work by modifying these requests and responses.

2

Foundation

Promises and asynchronous flow

Concept: Understand how promises handle asynchronous requests and responses.

When you make a request with Axios, it returns a promise. This promise waits for the server to respond. You use .then() to handle success and .catch() for errors. This lets your app keep running while waiting for data.

Result

You can write code that reacts to server responses or errors without freezing the app.

Knowing promises helps you understand how interceptors can modify requests or responses before your code handles them.

3

Intermediate

Adding request interceptors

🤔Before reading on: do you think request interceptors can modify the request headers or body? Commit to your answer.

Concept: Request interceptors let you change or add information to every request before it is sent.

You add a request interceptor with axios.interceptors.request.use(function(config) { /* modify config */ return config; }). For example, you can add an authorization token to headers so every request includes it automatically.

Result

Every request sent by Axios now includes the added headers or changes without repeating code.

Understanding request interceptors helps you centralize common request modifications, reducing errors and repetition.

4

Intermediate

Using response interceptors

🤔Before reading on: do you think response interceptors can catch errors globally or only after your code handles them? Commit to your answer.

Concept: Response interceptors let you handle or change data from the server before your code sees it.

You add a response interceptor with axios.interceptors.response.use(function(response) { return response; }, function(error) { /* handle error */ return Promise.reject(error); }). This can catch errors like expired tokens and trigger login or refresh automatically.

Result

Your app can handle server errors or modify responses in one place, improving consistency.

Knowing response interceptors allows you to manage errors and data transformations globally, simplifying your app logic.

5

Intermediate

Ejecting interceptors to avoid leaks

🤔Before reading on: do you think interceptors stay forever once added, or can they be removed? Commit to your answer.

Concept: Interceptors can be removed to prevent unwanted repeated effects or memory leaks.

When you add an interceptor, it returns an ID. You can remove it later with axios.interceptors.request.eject(id) or axios.interceptors.response.eject(id). This is useful in apps with dynamic behavior or tests.

Result

You avoid bugs caused by interceptors running multiple times or after they are no longer needed.

Knowing how to remove interceptors prevents subtle bugs and resource waste in complex apps.

6

Advanced

Chaining multiple interceptors

🤔Before reading on: do you think multiple interceptors run in the order added or in reverse? Commit to your answer.

Concept: You can add many interceptors that run one after another, allowing layered processing.

Interceptors run in the order they were added for requests, and in reverse order for responses. This lets you separate concerns, like logging, authentication, and error handling, each in its own interceptor.

Result

Your app can handle complex request/response flows cleanly and modularly.

Understanding interceptor order helps you design predictable and maintainable request pipelines.

7

Expert

Interceptor pitfalls and async traps

🤔Before reading on: do you think async code inside interceptors pauses the request or runs after? Commit to your answer.

Concept: Interceptors can use async code, but misuse can cause delays or unhandled errors.

If you use async functions in interceptors, Axios waits for them to finish before continuing. Mistakes like not returning promises or throwing inside interceptors can break requests silently. Proper error handling and returning promises is critical.

Result

Your app avoids hanging requests or hidden bugs caused by interceptor misuse.

Knowing how async works inside interceptors prevents hard-to-debug issues in production apps.

Under the Hood

Axios interceptors work by wrapping the request and response processes with functions that run before sending or after receiving data. Internally, Axios maintains arrays of interceptor functions. When a request is made, Axios runs each request interceptor in sequence, modifying the config object. After the server responds, Axios runs response interceptors in reverse order, allowing modification or error handling. This chaining uses JavaScript promises to handle asynchronous flow smoothly.

Why designed this way?

Interceptors were designed to separate concerns and avoid repeating code for common tasks like authentication or logging. Using promise chains allows asynchronous operations inside interceptors without blocking the main thread. The design balances flexibility and simplicity, letting developers add or remove interceptors dynamically. Alternatives like modifying each request manually were error-prone and hard to maintain, so interceptors provide a clean, centralized solution.

┌─────────────────────────────┐
│       Axios Request          │
│  (config object created)     │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│  Request Interceptors Array  │
│  (run in order added)        │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│       HTTP Request Sent      │
│       (to server)            │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│      HTTP Response Received  │
│       (from server)          │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Response Interceptors Array  │
│ (run in reverse order added) │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│    Promise resolves with     │
│    final response or error   │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do request interceptors run after the request is sent? Commit to yes or no.

Common Belief: Request interceptors run after the request is sent to the server.

Reality: Request interceptors run before the request is sent, allowing modification of the request config.

Why it matters: Believing this causes confusion about when to modify headers or data, leading to bugs where changes don't apply.

Quick: Do response interceptors catch errors only after your .catch() handlers? Commit to yes or no.

Common Belief: Response interceptors cannot catch errors before your code’s .catch() handlers.

Reality: Response interceptors run before your .catch() handlers, so they can handle or transform errors globally.

Why it matters: Misunderstanding this leads to duplicated error handling and inconsistent app behavior.

Quick: Can you add async code inside interceptors without returning a promise? Commit to yes or no.

Common Belief: You can add async code inside interceptors without returning promises, and it will work fine.

Reality: If you don’t return a promise or the async function’s result, Axios won’t wait, causing unexpected behavior or silent failures.

Why it matters: This causes requests to proceed before async tasks finish, leading to bugs like missing tokens or unhandled errors.

Quick: Do multiple interceptors run in the order they were added for both requests and responses? Commit to yes or no.

Common Belief: Multiple interceptors run in the order they were added for both requests and responses.

Reality: Request interceptors run in the order added, but response interceptors run in reverse order.

Why it matters: Ignoring this causes confusion about the flow of data and can break layered logic like logging or error handling.

Expert Zone

1

Interceptors can be used to implement token refresh logic by catching 401 errors and retrying requests transparently.

2

Ejecting interceptors is crucial in single-page apps to avoid stacking interceptors on route changes or component mounts.

3

Interceptors can modify config or response objects deeply, but careless mutations can cause side effects that are hard to debug.

When NOT to use

Avoid using interceptors for request-specific logic that only applies once or rarely; instead, modify those requests directly. For complex state management or retry logic, consider dedicated libraries or Vue plugins that handle authentication flows more robustly.

Production Patterns

In production Vue apps, interceptors commonly add authentication tokens, log request/response data for monitoring, handle global error messages, and refresh expired tokens automatically. They are often combined with Vuex or Pinia for state management and used with centralized API service modules.

Connections

Middleware in Express.js

Similar pattern of intercepting and modifying requests and responses in a chain.

Understanding Axios interceptors helps grasp how middleware works in backend frameworks, showing a shared design for handling requests step-by-step.

Aspect-Oriented Programming (AOP)

Interceptors implement cross-cutting concerns like logging or security, which is the core idea of AOP.

Knowing interceptors reveals how programming can separate concerns cleanly, improving modularity and maintainability.

Airport security checkpoints

Both involve sequential checks and modifications before allowing passage.

Recognizing this connection helps understand the importance of order and thoroughness in processing flows.

Common Pitfalls

#1 Adding an interceptor inside a component without removing it causes multiple interceptors stacking.

Wrong approach:

axios.interceptors.request.use(config => { config.headers['Auth'] = 'token'; return config; }); // called on every component mount

Correct approach:

const interceptorId = axios.interceptors.request.use(config => { config.headers['Auth'] = 'token'; return config; });
// later when component unmounts
axios.interceptors.request.eject(interceptorId);

Root cause:

Misunderstanding that interceptors persist globally and must be removed to avoid duplicates.

#2 Not returning the config or response object inside interceptors breaks the request chain.

Wrong approach:

axios.interceptors.request.use(config => { config.headers['Auth'] = 'token'; }); // missing return

Correct approach:

axios.interceptors.request.use(config => { config.headers['Auth'] = 'token'; return config; });

Root cause:

Forgetting that interceptors must return the modified object to continue the chain.

#3 Throwing errors inside interceptors without catching causes unhandled promise rejections.

Wrong approach:

axios.interceptors.response.use(response => response, error => { throw error; });

Correct approach:

axios.interceptors.response.use(response => response, error => { return Promise.reject(error); });

Root cause:

Confusing throwing with rejecting promises in async flows.

Key Takeaways

Axios interceptors let you automatically modify or handle every request and response in one place.

Request interceptors run before sending data, and response interceptors run after receiving data, each in specific order.

Properly returning values and handling async code inside interceptors is critical to avoid bugs.

Removing interceptors when no longer needed prevents bugs and memory leaks in dynamic apps.

Interceptors enable clean, centralized management of common tasks like authentication and error handling.

Practice

1. What is the main purpose of Axios interceptors in a Vue application?

easy

A. To modify requests or responses globally before they reach your components

B. To create new Axios instances for each API call

C. To replace Vue lifecycle hooks with Axios methods

D. To automatically refresh the Vue component state

Solution

1. Step 1: Understand Axios interceptors role

   Axios interceptors allow you to intercept and modify requests or responses globally before they reach your Vue components.

2. Step 2: Compare options

   Options B, C, and D describe unrelated or incorrect uses of Axios interceptors.

3. Final Answer:

   To modify requests or responses globally before they reach your components -> Option A

4. Quick Check:

   Interceptor purpose = Modify requests/responses globally [OK]

Hint: Interceptors act like global filters for requests and responses [OK]

Common Mistakes:

• Thinking interceptors create new Axios instances
• Confusing interceptors with Vue lifecycle hooks
• Assuming interceptors update component state automatically

2. Which of the following is the correct syntax to add a request interceptor using Axios in Vue?

easy

A. axios.use.interceptors.request(config => { return config })

B. axios.request.interceptors.use(config => { return config })

C. axios.interceptors.request.use(config => { return config })

D. axios.interceptors.use.request(config => { return config })

Solution

1. Step 1: Recall Axios interceptor syntax

   The correct syntax to add a request interceptor is axios.interceptors.request.use(callback).

2. Step 2: Identify correct option

   Only axios.interceptors.request.use(config => { return config }) matches the correct syntax; others have incorrect property order or method calls.

3. Final Answer:

   axios.interceptors.request.use(config => { return config }) -> Option C

4. Quick Check:

   Correct syntax = axios.interceptors.request.use [OK]

Hint: Remember: interceptors.request.use is the correct chain [OK]

Common Mistakes:

• Swapping 'request' and 'interceptors' order
• Using 'use' before 'interceptors'
• Missing the return of config in the callback

3. Given this Axios response interceptor code in Vue:

axios.interceptors.response.use(response => {
  response.data.modified = true;
  return response;
});

const result = await axios.get('/api/data');
console.log(result.data.modified);

What will be logged to the console?

medium

A. undefined

B. true

C. false

D. An error will occur

Solution

1. Step 1: Analyze the response interceptor

   The interceptor adds a property 'modified' with value true to response.data before returning it.

2. Step 2: Understand the logged value

   After the GET request, result.data.modified will be true because the interceptor modified it.

3. Final Answer:

   true -> Option B

4. Quick Check:

   Interceptor modifies data = logged true [OK]

Hint: Interceptors can add properties to response data before use [OK]

Common Mistakes:

• Assuming interceptor does not modify response
• Expecting undefined because property was added dynamically
• Thinking an error occurs due to property addition

4. Identify the error in this Vue Axios interceptor code:

axios.interceptors.request.use(config => {
  config.headers['Authorization'] = 'Bearer token';
});

medium

A. Missing return of config in the interceptor callback

B. Headers should be set on response, not config

C. Authorization header value must be a function

D. Interceptor should be added on axios.request, not axios.interceptors

Solution

1. Step 1: Check interceptor callback requirements

   Axios interceptors must return the config object after modifying it to continue the request chain.

2. Step 2: Identify missing return

   The code modifies headers but does not return config, causing the request to hang or fail.

3. Final Answer:

   Missing return of config in the interceptor callback -> Option A

4. Quick Check:

   Always return config in request interceptor [OK]

Hint: Always return config or response in interceptors [OK]

Common Mistakes:

• Forgetting to return config or response
• Setting headers on response instead of request config
• Misplacing interceptor on wrong Axios property

5. You want to globally handle 401 Unauthorized errors in your Vue app using Axios interceptors. Which approach correctly implements this behavior?

hard

A. Use a response interceptor to retry the request infinitely on 401 errors

B. Use a request interceptor to modify the request URL on 401 errors

C. Use a request interceptor to add a 401 status header before sending

D. Use a response interceptor to check error response status and redirect to login

Solution

1. Step 1: Understand 401 error handling

   401 Unauthorized errors come from server responses, so handling must be in a response interceptor.

2. Step 2: Choose correct handling method

   Use a response interceptor to check error response status and redirect to login correctly uses a response interceptor to detect 401 status and redirect user to login page.

3. Step 3: Eliminate incorrect options

   Retrying infinitely causes loops; using a request interceptor cannot handle response errors like 401; adding a 401 status header in the request is invalid.

4. Final Answer:

   Use a response interceptor to check error response status and redirect to login -> Option D

5. Quick Check:

   401 errors handled in response interceptor [OK]

Hint: Handle server errors in response interceptors, not request ones [OK]

Common Mistakes:

• Trying to handle response errors in request interceptors
• Retrying requests infinitely on 401 errors
• Adding fake status headers in requests