Navigation guards (beforeEach, beforeEnter) in Vue - Deep Dive

Overview - Navigation guards (beforeEach, beforeEnter)

What is it?

Navigation guards in Vue are special functions that run before or during a route change. They let you control if a user can go to a new page or not. Two common types are beforeEach, which runs before every route change, and beforeEnter, which runs before entering a specific route. These guards help manage access and actions during navigation.

Why it matters

Without navigation guards, users could access pages they shouldn't, like private areas without logging in. This could cause security issues or broken app states. Guards let developers check conditions, redirect users, or stop navigation, making apps safer and smoother. They improve user experience by controlling navigation flow based on rules.

Where it fits

Before learning navigation guards, you should understand Vue Router basics like routes and components. After mastering guards, you can explore advanced routing features like dynamic routing, lazy loading, and route meta fields. Navigation guards fit in the middle of learning Vue Router, bridging simple routing and complex navigation control.

Mental Model

Core Idea

Navigation guards act like gatekeepers that check conditions before allowing a user to move to a new page in a Vue app.

Think of it like...

Imagine a security guard at a building entrance who checks your ID before letting you in. If you don’t have permission, they stop you or send you somewhere else.

┌───────────────┐
│ User clicks   │
│ a link/button │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ beforeEach    │
│ guard runs    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ beforeEnter   │
│ guard runs    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Route change  │
│ allowed or    │
│ blocked       │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

What are Vue Navigation Guards

Concept: Introduction to navigation guards as functions that run during route changes.

Vue Router lets you define functions called navigation guards that run before or after a route changes. They help you decide if the user can go to the new page or not. The simplest guard is beforeEach, which runs before every route change.

Result

You understand that navigation guards are checks that happen automatically when routes change.

Understanding that navigation guards are automatic checks helps you see how Vue controls navigation flow behind the scenes.

2

Foundation

Difference Between beforeEach and beforeEnter

Concept: Learn the two main types of guards and when each runs.

beforeEach is a global guard that runs before every route change. beforeEnter is a route-specific guard that runs only before entering a particular route. This means beforeEach can control all navigation, while beforeEnter controls just one route.

Result

You can tell when to use global guards versus route-specific guards.

Knowing the scope of each guard type helps you organize your navigation logic efficiently.

3

Intermediate

Using beforeEach for Authentication Checks

🤔Before reading on: do you think beforeEach can stop navigation if a user is not logged in? Commit to yes or no.

Concept: Use beforeEach to check if a user is logged in before allowing route changes.

You can add a beforeEach guard that checks if the user is logged in before moving to a new page. If not logged in, you can redirect them to a login page. This prevents unauthorized access globally.

Result

Users who are not logged in get redirected to login before accessing protected pages.

Understanding that beforeEach runs before every route lets you enforce app-wide rules like authentication.

4

Intermediate

Using beforeEnter for Route-Specific Logic

🤔Before reading on: do you think beforeEnter can redirect users only for one route? Commit to yes or no.

Concept: Use beforeEnter to run checks or actions only when entering a specific route.

You can add a beforeEnter guard inside a route definition. This guard runs only when navigating to that route. For example, you might check if a user has special permissions for that page and redirect if not.

Result

Only navigation to that route triggers the guard, allowing fine control per page.

Knowing that beforeEnter is route-specific helps you keep checks localized and avoid unnecessary global logic.

5

Intermediate

How to Control Navigation Flow

🤔Before reading on: do you think navigation guards can delay navigation or cancel it? Commit to yes or no.

Concept: Navigation guards can allow, redirect, or cancel navigation based on conditions.

Inside a guard, you call next() to allow navigation, next('/path') to redirect, or next(false) to cancel. This lets you control exactly what happens when a user tries to go somewhere.

Result

Navigation can be stopped, redirected, or allowed dynamically.

Understanding the next() function is key to controlling navigation behavior precisely.

6

Advanced

Handling Asynchronous Checks in Guards

🤔Before reading on: can navigation guards wait for async operations like API calls? Commit to yes or no.

Concept: Navigation guards support asynchronous operations to check conditions before navigation.

You can perform async tasks like fetching user data or permissions inside guards by returning a Promise or using async/await. Navigation waits until the async check finishes before proceeding or blocking.

Result

Navigation can depend on data loaded asynchronously, enabling dynamic access control.

Knowing guards support async lets you build real-world checks that depend on server data.

7

Expert

Common Pitfalls and Performance Considerations

🤔Before reading on: do you think adding many global guards slows down navigation? Commit to yes or no.

Concept: Understanding how multiple guards affect app performance and how to avoid common mistakes.

Using many global guards or heavy async operations can slow navigation and cause flickers. Also, forgetting to call next() or calling it multiple times causes errors. Experts carefully organize guards and optimize async checks to keep navigation smooth.

Result

You avoid navigation delays and errors by managing guards wisely.

Knowing the performance impact and common errors helps you write guards that keep apps fast and stable.

Under the Hood

Vue Router runs navigation guards in a sequence before changing routes. It calls each guard function with the current route, the target route, and a next callback. The next callback controls if navigation continues, redirects, or cancels. For async guards, Vue Router waits for the Promise to resolve before proceeding. This mechanism ensures all checks complete before the page changes.

Why designed this way?

This design allows flexible control over navigation flow while keeping the routing process predictable. Using a next callback and Promise support lets developers write both simple and complex guards. Alternatives like blocking UI or synchronous checks would reduce flexibility and user experience. The callback pattern was chosen for clear control and compatibility with async operations.

┌───────────────┐
│ Navigation    │
│ triggered     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Run beforeEach│
│ guards in     │
│ order         │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Run beforeEnter│
│ guard for     │
│ target route  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Wait for next │
│ callback or   │
│ Promise       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Proceed with  │
│ route change  │
│ or redirect   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does beforeEnter run on every route change or only on its route? Commit to one.

Common Belief: beforeEnter runs before every route change like beforeEach.

Reality: beforeEnter runs only before entering the specific route it is defined on.

Why it matters: Misusing beforeEnter as a global guard can cause missed checks or unexpected behavior.

Quick: Can you call next() multiple times in one guard? Commit yes or no.

Common Belief: Calling next() multiple times in a guard is fine and does not cause issues.

Reality: Calling next() more than once causes errors and breaks navigation flow.

Why it matters: Multiple next() calls lead to confusing bugs and app crashes during navigation.

Quick: Do navigation guards block UI rendering until they finish? Commit yes or no.

Common Belief: Navigation guards block the entire UI until they complete.

Reality: Guards block route changes but the current page remains visible until navigation finishes.

Why it matters: Expecting UI to freeze can cause misunderstanding of user experience during navigation.

Quick: Can navigation guards run asynchronous code? Commit yes or no.

Common Belief: Navigation guards cannot handle asynchronous operations properly.

Reality: Navigation guards support async code by returning Promises or using next callbacks.

Why it matters: Not knowing this limits guard usage to simple checks, missing real-world needs.

Expert Zone

1

Global beforeEach guards run in the order they are registered, so order matters for complex apps.

2

Route meta fields combined with guards allow flexible, declarative access control without hardcoding logic.

3

Using next(false) cancels navigation but does not trigger error handling, which can confuse debugging.

When NOT to use

Avoid using heavy logic or long async calls inside navigation guards as it delays navigation and hurts user experience. Instead, use route-level lazy loading or state management to handle complex checks outside guards.

Production Patterns

In real apps, beforeEach is often used for authentication and logging, while beforeEnter handles route-specific permissions. Guards are combined with route meta fields and Vuex or Pinia state for clean, maintainable access control.

Connections

Middleware in Web Servers

Navigation guards work like middleware that intercept requests before reaching the final handler.

Understanding middleware helps grasp how guards intercept and control navigation flow in Vue apps.

Event Listeners in UI Programming

Guards act like event listeners that react to navigation events before they complete.

Knowing event-driven programming clarifies how guards hook into route changes to run logic.

Security Checkpoints in Physical Access Control

Both enforce rules before allowing entry, ensuring only authorized access.

Seeing guards as security checkpoints highlights their role in protecting app routes from unauthorized use.

Common Pitfalls

#1 Forgetting to call next() inside a guard, causing navigation to hang.

Wrong approach:

router.beforeEach((to, from) => {
if (!isLoggedIn()) {
router.push('/login')
}
})

Correct approach:

router.beforeEach((to, from, next) => {
if (!isLoggedIn()) {
next('/login')
} else {
next()
}
})

Root cause:

Misunderstanding that next() must be called to continue or redirect navigation.

#2 Calling next() multiple times in one guard, causing errors.

Wrong approach:

router.beforeEach((to, from, next) => {
next()
next('/home')
})

Correct approach:

router.beforeEach((to, from, next) => {
if (to.path === '/home') {
next()
} else {
next('/home')
}
})

Root cause:

Not realizing next() must be called exactly once per guard invocation.

#3 Putting heavy async logic directly in guards causing slow navigation.

Wrong approach:

router.beforeEach(async (to, from, next) => {
await fetchLargeData()
next()
})

Correct approach:

Use route lazy loading or prefetch data outside guards, keep guards fast:
router.beforeEach((to, from, next) => {
if (hasPermission()) {
next()
} else {
next('/login')
}
})

Root cause:

Not considering user experience impact of slow guards.

Key Takeaways

Navigation guards in Vue control route changes by running checks before navigation happens.

beforeEach guards run globally on every route change, while beforeEnter guards run only for specific routes.

Guards use a next() callback to allow, redirect, or cancel navigation, enabling flexible control.

They support asynchronous operations, allowing real-world checks like authentication and permissions.

Proper use of guards improves app security, user experience, and navigation flow control.

Practice

1. What is the main purpose of Vue Router's beforeEach navigation guard?

easy

A. To run a function before every route change globally

B. To run a function only after a route has been entered

C. To modify the route's component before rendering

D. To delay the route change indefinitely

Solution

1. Step 1: Understand the role of beforeEach

   beforeEach is a global navigation guard that runs before every route change in the app.

2. Step 2: Compare options with the guard's behavior

   To run a function before every route change globally correctly states it runs before every route change globally. Other options describe incorrect or unrelated behaviors.

3. Final Answer:

   To run a function before every route change globally -> Option A

4. Quick Check:

   Global guard before route change = A [OK]

Hint: beforeEach runs before every route change globally [OK]

Common Mistakes:

• Confusing beforeEach with afterEach
• Thinking beforeEach runs only on specific routes
• Assuming beforeEach modifies components directly

2. Which of the following is the correct syntax to add a beforeEnter guard to a route in Vue Router?

easy

A. { path: '/home', component: Home, beforeEnter(to, from, next) { next() } }

B. { path: '/home', component: Home, beforeEnter: function(to, from, next) { next() } }

C. { path: '/home', component: Home, beforeEnter: (to, from, next) => { next() } }

D. router.beforeEnter('/home', (to, from, next) => next())

Solution

1. Step 1: Identify correct route object syntax

   Vue Router expects beforeEnter as a property with a function value inside the route object.

2. Step 2: Check each option's syntax

   { path: '/home', component: Home, beforeEnter: function(to, from, next) { next() } } uses beforeEnter: function(to, from, next) { next() } which is valid. { path: '/home', component: Home, beforeEnter(to, from, next) { next() } } misses the colon. { path: '/home', component: Home, beforeEnter: (to, from, next) => { next() } } uses arrow function which is valid but less common in examples. router.beforeEnter('/home', (to, from, next) => next()) is invalid syntax for route config.

3. Final Answer:

   { path: '/home', component: Home, beforeEnter: function(to, from, next) { next() } } -> Option B

4. Quick Check:

   Route guard syntax uses colon and function = C [OK]

Hint: Use colon and function for beforeEnter in route object [OK]

Common Mistakes:

• Omitting colon before beforeEnter
• Trying to call beforeEnter on router instance
• Using arrow function without colon

3. Given this Vue Router setup, what will happen when navigating to /dashboard?

const router = createRouter({
  history: createWebHistory(),
  routes: [
    { path: '/login', component: Login },
    { path: '/dashboard', component: Dashboard, beforeEnter(to, from, next) {
      if (!isLoggedIn()) next('/login')
      else next()
    } }
  ]
})

router.beforeEach((to, from, next) => {
  console.log('Global guard')
  next()
})

medium

A. Navigation blocked with no console output

B. Console logs 'Global guard' and navigates to /dashboard regardless

C. Console logs 'Global guard' and navigates to /login if not logged in

D. Syntax error due to missing next() call

Solution

1. Step 1: Analyze global beforeEach guard

   The global guard logs 'Global guard' and calls next(), so navigation proceeds.

2. Step 2: Analyze route-specific beforeEnter guard

   beforeEnter checks if user is logged in. If not, it redirects to '/login'. Otherwise, it allows navigation.

3. Final Answer:

   Console logs 'Global guard' and navigates to /login if not logged in -> Option C

4. Quick Check:

   Global guard logs + route guard redirects if not logged in = A [OK]

Hint: Global guard runs first, then route guard decides next step [OK]

Common Mistakes:

• Ignoring global guard console log
• Assuming navigation always succeeds
• Forgetting next() call in guards

4. Identify the error in this Vue Router navigation guard code:

router.beforeEach((to, from, next) => {
  if (to.meta.requiresAuth) {
    if (!userIsLoggedIn) {
      next('/login')
    }
  }
  next()
})

medium

A. Missing call to next() inside the if block causes navigation to continue twice

B. userIsLoggedIn should be a function call

C. to.meta.requiresAuth is not a valid property

D. next() is called twice, causing navigation to fail

Solution

1. Step 1: Trace next() calls in the guard

   If to.meta.requiresAuth is true and user is not logged in, next('/login') is called. Then outside the if block, next() is called again unconditionally.

2. Step 2: Understand consequences of calling next() twice

   Calling next() twice causes Vue Router to throw an error and navigation fails.

3. Final Answer:

   next() is called twice, causing navigation to fail -> Option D

4. Quick Check:

   Two next() calls in one guard = B [OK]

Hint: Call next() only once per guard to avoid errors [OK]

Common Mistakes:

• Calling next() multiple times in one guard
• Not returning after next('/login')
• Assuming meta is always defined

5. You want to protect a nested route /admin/settings so that only logged-in users can access it. You have a global beforeEach guard and a route-level beforeEnter guard on /admin. Which approach correctly ensures the user is redirected to /login if not logged in, without redundant checks?

hard

A. Check login only in global beforeEach; remove beforeEnter guard from /admin route

B. Check login only in beforeEnter guard on /admin; global beforeEach does not check login

C. Check login in both global beforeEach and beforeEnter guard on /admin

D. Do not check login in any guard; rely on component logic

Solution

1. Step 1: Understand guard execution order and redundancy

   Global beforeEach runs before every route, including nested ones. Route-level beforeEnter runs after global guards.

2. Step 2: Avoid redundant login checks

   Checking login in both guards causes duplicate redirects and complexity. Checking only in global guard covers all routes.

3. Final Answer:

   Check login only in global beforeEach; remove beforeEnter guard from /admin route -> Option A

4. Quick Check:

   Single global guard for login check avoids redundancy = A [OK]

Hint: Use global guard for login checks to avoid duplicate logic [OK]

Common Mistakes:

• Duplicating login checks in multiple guards
• Relying on component logic instead of guards
• Ignoring nested route guard order