What if you never had to repeat your API setup code again?
Why Axios interceptors in Vue? - Purpose & Use Cases
Imagine you have to add a token to every API request and handle errors manually in every single call across your Vue app.
Manually adding headers and error handling everywhere is repetitive, easy to forget, and makes your code messy and hard to maintain.
Axios interceptors let you automatically modify requests and responses in one place, so you don't repeat code and can handle errors globally.
axios.get('/data', { headers: { Authorization: 'token' } }).catch(err => handleError(err));
axios.interceptors.request.use(config => { config.headers.Authorization = 'token'; return config; });You can centralize request and response logic, making your app cleaner, more reliable, and easier to update.
In a Vue app, you can refresh expired tokens automatically before requests and show a global error message if the server is down.
Manually adding headers and error handling everywhere is tedious and error-prone.
Axios interceptors let you handle these tasks in one place.
This leads to cleaner, more maintainable Vue applications.
Practice
Solution
Step 1: Understand Axios interceptors role
Axios interceptors allow you to intercept and modify requests or responses globally before they reach your Vue components.Step 2: Compare options
Options B, C, and D describe unrelated or incorrect uses of Axios interceptors.Final Answer:
To modify requests or responses globally before they reach your components -> Option AQuick Check:
Interceptor purpose = Modify requests/responses globally [OK]
- Thinking interceptors create new Axios instances
- Confusing interceptors with Vue lifecycle hooks
- Assuming interceptors update component state automatically
Solution
Step 1: Recall Axios interceptor syntax
The correct syntax to add a request interceptor is axios.interceptors.request.use(callback).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.Final Answer:
axios.interceptors.request.use(config => { return config }) -> Option CQuick Check:
Correct syntax = axios.interceptors.request.use [OK]
- Swapping 'request' and 'interceptors' order
- Using 'use' before 'interceptors'
- Missing the return of config in the callback
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?
Solution
Step 1: Analyze the response interceptor
The interceptor adds a property 'modified' with value true to response.data before returning it.Step 2: Understand the logged value
After the GET request, result.data.modified will be true because the interceptor modified it.Final Answer:
true -> Option BQuick Check:
Interceptor modifies data = logged true [OK]
- Assuming interceptor does not modify response
- Expecting undefined because property was added dynamically
- Thinking an error occurs due to property addition
axios.interceptors.request.use(config => {
config.headers['Authorization'] = 'Bearer token';
});Solution
Step 1: Check interceptor callback requirements
Axios interceptors must return the config object after modifying it to continue the request chain.Step 2: Identify missing return
The code modifies headers but does not return config, causing the request to hang or fail.Final Answer:
Missing return of config in the interceptor callback -> Option AQuick Check:
Always return config in request interceptor [OK]
- Forgetting to return config or response
- Setting headers on response instead of request config
- Misplacing interceptor on wrong Axios property
Solution
Step 1: Understand 401 error handling
401 Unauthorized errors come from server responses, so handling must be in a response interceptor.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.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.Final Answer:
Use a response interceptor to check error response status and redirect to login -> Option DQuick Check:
401 errors handled in response interceptor [OK]
- Trying to handle response errors in request interceptors
- Retrying requests infinitely on 401 errors
- Adding fake status headers in requests
Ready to prove it?
Pass the test and this pattern moves unknown
