Guards & Nested Routes — Series 3

Preview — 3 of 10 questions

What does this let an app do that static routes: [...] configuration alone can't?

javascript

async function loadPluginRoutes() {
  const manifest = await fetchPluginManifest()
  for (const plugin of manifest.plugins) {
    router.addRoute({
      path: plugin.path,
      name: plugin.name,
      component: () => import(/* @vite-ignore */ plugin.entryUrl),
    })
  }
}

AaddRoute registers a new route on an already-running router instance, after initial setup — useful exactly for scenarios like this, where the full set of routes isn't known until runtime (loaded from a plugin manifest, a feature-flag service, or a CMS), letting the app extend its own routing table dynamically instead of requiring every possible route to be hardcoded up front

BaddRoute only works before router.install() is called — calling it after the app has mounted throws

CaddRoute is purely for internal use by <router-view> and isn't part of the public API

DaddRoute replaces the router's entire route table with just the newly added route

Why might an app need this alongside addRoute?

javascript

router.addRoute({ path: '/beta-feature', name: 'beta', component: BetaFeature })
// ... later, if the feature flag is disabled ...
router.removeRoute('beta')

AremoveRoute only works on routes that were statically defined in the original routes: [...] array, not ones added via addRoute

BThere's no such method — routes, once added, exist for the lifetime of the app; the only way to "remove" one is a full page reload

CremoveRoute removes the route's component from memory but leaves its path still matchable, now rendering a blank page

DRoutes added dynamically (say, when a feature flag enables a beta section) may need to be removed again if that flag is later disabled during the same session — removeRoute(name) unregisters a route by its name, so navigating to its old path afterward correctly falls through to a 404/catch-all instead of continuing to resolve to the now-supposed-to-be-disabled feature

What's the purpose of pairing beforeEach and afterEach like this?

javascript

router.beforeEach((to, from, next) => {
  NProgress.start()
  next()
})

router.afterEach(() => {
  NProgress.done()
})

AbeforeEach fires as every navigation begins and afterEach fires once it's fully resolved (whether that took a moment for a lazy-loaded route chunk to download, or an async guard to resolve) — starting a loading-bar animation in the first and stopping it in the second gives visual feedback for navigations that take a noticeable amount of time, without needing every single route/component to manage that UI itself

BafterEach only fires on failed navigations; successful ones skip straight past it

CThis pattern actually blocks navigation until NProgress.done() is manually called — it's a way to pause routing until an async task finishes

DThis code has a bug: beforeEach's next() call must happen after NProgress.start() resolves as a Promise, which it doesn't here

Answer all 10 questions (7 more), see explanations for every answer, and track your score.