16. مثال [nuxt-13]: بررسی ناوبری [nuxt-12]

در این مثال، ما در حال بررسی ناوبری برای [nuxt-12] هستیم. ما این کار را برای [nuxt-12] انجام ندادیم زیرا بررسی ناوبری، پیچیدگی بیشتری به مثالی که از قبل پیچیده بود، اضافه می‌کرد.

هدف: ما می‌خواهیم اطمینان حاصل کنیم که کاربر فقط بتواند اقدامات مجاز را انجام دهد:

• اگر جلسه jSON شروع نشده باشد، تنها URL و [/] مجاز هستند؛
• اگر جلسه jSON آغاز شده باشد اما کاربر احراز هویت نشده باشد، تنها جلسات URL و [/authentification] مجاز هستند؛
• اگر جلسه jSON آغاز شده و کاربر احراز هویت شده باشد، آنگاه فقط جلسات URL و [/get-admindata, /fin-session] مجاز هستند؛
• وقتی هدف مسیریابی فعلی مجاز نباشد، هدایت به یک URL مجاز انجام خواهد شد؛

نمونه [nuxt-13] در ابتدا با کپی کردن نمونه [nuxt-12] به دست می‌آید:

تغییرات در پوشه مسیریابی [middleware] انجام خواهد شد.

16.1. مسیر‌یابی برای برنامه [nuxt]

مسیربندی برنامه در فایل [nuxt.config] به شرح زیر پیکربندی شده است:

// روتر
  router: {
    //ریشهٔ برنامهٔ URL
    base: '/nuxt-13/',
    // میان‌افزار مسیریابی
    middleware: ['routing']
},

• خط ۶: مسیریابی برنامه توسط فایل [middleware/routing] کنترل می‌شود؛

فایل [middleware/routing] به شرح زیر است:

/* eslint-disable no-console */

// ما middleware سرور و کلاینت را وارد می‌کنیم
import serverRouting from './server/routing'
import clientRouting from './client/routing'

export default function(context) {
  // چه کسی این کد را اجرا می‌کند؟
  console.log('[middleware], process.server', process.server, ', process.client=', process.client)
  if (process.server) {
    //مسیریابی سرور
    serverRouting(context)
  } else {
    // مسیر‌یابی کلاینت
    clientRouting(context)
  }
}

• خطوط ۱۰–۱۶: مسیریابی برای کلاینت و سرور [nuxt] به شیوه‌ای متفاوت انجام می‌شود. این نقطه‌ای است که آن‌ها به طور قابل توجهی با هم تفاوت دارند؛
• خط ۴: مسیریابی سرور توسط اسکریپت [middleware/server/routing] پیاده‌سازی می‌شود؛
• خط ۵: مسیریابی سمت کلاینت توسط اسکریپت [middleware/client/routing] پیاده‌سازی می‌شود؛

16.2. مسیر‌یابی کلاینت [nuxt]

مسیر‌یابی مشتری در [nuxt] همانند [nuxt-12] باقی می‌ماند:

/* eslint-disable no-console */
export default function(context) {
  // چه کسی این کد را اجرا می‌کند؟
  console.log('[middleware client], process.server', process.server, ', process.client=', process.client)
  // پردازش کوکی جلسه PHP در مرورگر
  //کوکی جلسه مرورگر PHP باید دقیقاً مشابه کوکی یافت‌شده در جلسه Nuxt باشد
  // عمل [fin-session] یک کوکی جدید PHP دریافت می‌کند (هم سرور و هم کلاینت Nuxt)
  //اگر سرور آن را دریافت کند، کلاینت باید آن را به مرورگر منتقل کند
  //برای ارتباطات خود با سرور PHP
  //این یک سناریوی مسیریابی سمت کلاینت است

  //کوکی جلسه بازیابی می‌شود: PHP
  const phpSessionCookie = context.store.state.phpSessionCookie
  if (phpSessionCookie) {
    // اگر وجود داشته باشد، کوکی جلسه PHP به مرورگر اختصاص داده می‌شود
    document.cookie = phpSessionCookie
  }

  ...
}

برای جلوگیری از دسترسی مشتری به مسیرهای غیرمجاز، ما صرفاً مسیرهای مجاز را در منوی ناوبری مشتری ارائه می‌دهیم. کامپوننت [components/navigation] به شرح زیر درمی‌آید:

<template>
  <!--منوی بوت‌استرپ با سه گزینه -->
  <b-nav vertical>
    <b-nav-item v-if="$store.state.jsonSessionStarted && !$store.state.userAuthenticated" to="/authentification" exact exact-active-class="active">
      Authentification
    </b-nav-item>
    <b-nav-item
      v-if="$store.state.jsonSessionStarted && $store.state.userAuthenticated && !$store.state.adminData"
      to="/get-admindata"
      exact
      exact-active-class="active"
    >
      Requête AdminData
    </b-nav-item>
    <b-nav-item v-if="$store.state.jsonSessionStarted && $store.state.userAuthenticated" to="/fin-session" exact exact-active-class="active">
      Fin session impôt
    </b-nav-item>
  </b-nav>
</template>

• خط ۴: گزینه [Authentification] تنها در صورتی ارائه می‌شود که جلسه jSON آغاز شده باشد اما کاربر احراز هویت نشده باشد. اگر جلسه jSON شروع نشده باشد یا کاربر قبلاً احراز هویت شده باشد، آنگاه این گزینه ارائه نمی‌شود؛
• خطوط ۷–۱۱: گزینه [Requête AdminData] تنها در صورتی ارائه می‌شود که جلسه jSON آغاز شده باشد، کاربر احراز هویت شده باشد و داده‌های [AdminData] هنوز بازیابی نشده باشد. اگر هر یک از این سه شرط برقرار نباشد (جلسه jSON شروع نشده باشد، کاربر احراز هویت نشده باشد، یا داده‌های [AdminData] قبلاً بازیابی شده باشد)، این گزینه ارائه نمی‌شود؛
• خط ۱۵: گزینه [Fin session impôt] به محض اینکه جلسه jSON آغاز شده و کاربر احراز هویت شده باشد، ارائه می‌شود؛ در غیر این صورت، ارائه نمی‌شود؛

16.3. مسیر‌یابی برای سرور [nuxt]

مسیر‌یابی سرور عموماً پیچیده‌تر از مسیر‌یابی کلاینت است زیرا کاربر می‌تواند هر URL را در نوار آدرس مرورگر خود تایپ کند. ما می‌توانیم یا اجازه دهیم این اتفاق بیفتد (در نهایت، کاربر قرار نیست این کار را انجام دهد) یا سعی کنیم آن را کنترل کنیم. در این مثال، همین کار را انجام خواهیم داد، زیرا در مورد برنامه [nuxt-12]، می‌توانیم به راحتی از آن صرف‌نظر کنیم، چرا که سرور محاسبه مالیات در برابر چنین ورودی‌های دستی URL به خوبی محافظت شده و می‌داند چگونه پیام‌های خطای مناسب را ارسال کند. ما این را در [next-12] دیدیم، جایی که هیچ کنترل مسیریابی وجود نداشت.

روتینگ در یک سرور [nuxt] از نظر مسیریابی با روتینگ در یک کلاینت [nuxt] تفاوت قابل توجهی دارد:

• وقتی یک سرور [nuxt] هدایت می‌شود، یک دستور هدایت را به مرورگر کلاینت ارسال می‌کند و هدف هدایت را مشخص می‌نماید. سپس مرورگر یک درخواست جدید به سرور [nuxt] ارسال می‌کند و درخواست آن هدف را که به آن منتقل شده است، مطرح می‌نماید. این دقیقاً مانند این است که کاربر آدرس URL مقصد هدایت را به صورت دستی وارد کرده باشد: کل برنامه [nuxt] مجدداً راه‌اندازی می‌شود و با آن کل چرخه عمر آن (پلاگین‌های سرور، فروشگاه، مسیریابی سرور، صفحات) نیز آغاز می‌شود؛
• اما زمانی که یک کلاینت با شناسه [nuxt] هدایت (redirect) می‌شود، چنین اتفاقی نمی‌افتد. در این حالت صرفاً یک تغییر صفحه رخ می‌دهد، درست مانند زمانی که کاربر روی لینکی که به هدف هدایت منتهی می‌شود کلیک کرده باشد. بنابراین چرخه عمر متفاوت است (مسیر‌یابی سمت کلاینت، نمایش هدف مسیر)؛

به همین دلیل، ترجیح داده می‌شود که مسیریابی سمت کلاینت از مسیریابی سمت سرور جدا شود، حتی اگر این دو مجموعه کد ممکن است شبیه به هم به نظر برسند.

اسکریپت مسیریابی سرور [middleware/server/routing] به شرح زیر خواهد بود:

/*eslint-disable no-console */
export default function(context) {
  // چه کسی این کد را اجرا می‌کند؟
  console.log('[middleware server], process.server', process.server, ', process.client=', process.client)

  //ما برخی اطلاعات را از فروشگاه [nuxt] بازیابی می‌کنیم
  const store = context.store
  // از کجا آمده‌ایم؟
  const from = store.state.from || 'nowhere'
  ...
}

• در مسیریابی سمت کلاینت، تابع مسیریابی زمینه [context] را به همراه ویژگی [context.from] دریافت می‌کند که مسیر صفحه‌ای است که کاربر از آن آمده است. مسیری که کاربر به آن می‌رود از طریق [context.route] به دست می‌آید؛
• در مسیریابی سمت سرور، تابع مسیریابی زمینه [context] را بدون ویژگی [context.from] دریافت می‌کند. مسیر‌یابی سرور تنها زمانی وارد عمل می‌شود که یک URL به‌صورت دستی از سرور [nuxt] درخواست شود. ما می‌دانیم که در این حالت، کل برنامه [nuxt] ریست می‌شود. گویی از ابتدا شروع می‌کنیم و بنابراین مفهومی به نام «صفحه قبلی» وجود ندارد؛
• به لطف جلسه [nuxt]، می‌دانیم که سرور می‌تواند این جلسه را بازیابی کند و بنابراین نیازی به شروع از ابتدا ندارد. بنابراین این در همین جلسه [nuxt] – و به طور مشخص‌تر در ذخیره‌گاه این جلسه – است که ما نام آخرین صفحه‌ای را که قبل از درخواست یک URL از سرور [nuxt] نمایش داده شده بود، ذخیره خواهیم کرد؛
• خطوط ۷–۹: ما نام آخرین صفحه‌ای را که توسط مرورگر مشتری نمایش داده شده است، بازیابی می‌کنیم. وقتی برنامه اجرا می‌شود، این اطلاعات در فروشگاه وجود ندارد. سپس نام [nowhere] به متغیر [from] اختصاص داده می‌شود؛

برای اینکه سرور [nuxt] بتواند نام آخرین صفحه‌ای را که توسط مرورگر مشتری نمایش داده شده از مخزن بازیابی کند، مشتری [nuxt] نیز باید این اطلاعات را در مخزن قرار دهد. بنابراین، اسکریپت مسیریابی برای مشتری [nuxt] به شرح زیر تکمیل می‌شود:

/* eslint-disable no-console */
export default function(context) {
  //چه کسی این کد را اجرا می‌کند؟
  console.log('[middleware client], process.server', process.server, ', process.client=', process.client)
  // پردازش کوکی جلسه PHP در مرورگر
  //کوکی جلسه مرورگر PHP باید دقیقاً مشابه کوکی یافت‌شده در جلسه Nuxt باشد
  // عمل [fin-session] یک کوکی جدید PHP دریافت می‌کند (هم سرور و هم کلاینت Nuxt)
  // اگر سرور آن را دریافت کند، کلاینت باید آن را به مرورگر منتقل کند
  //برای ارتباطات خود با سرور PHP
  //این یک سناریوی مسیریابی سمت کلاینت است

  //کوکی جلسه بازیابی می‌شود: PHP
  const phpSessionCookie = context.store.state.phpSessionCookie
  if (phpSessionCookie) {
    // اگر وجود داشته باشد، کوکی جلسه PHP به مرورگر اختصاص داده می‌شود
    document.cookie = phpSessionCookie
  }

  //نام صفحه‌ای که قرار است به آن برویم در جلسه ذخیره می‌شود – بدون هدایت سمت سرور
  context.store.commit('replace', { serverRedirection: false, from: context.route.name })
  //فروشگاه در جلسه ذخیره می‌شود [nuxt]
  const session = context.app.$session()
  session.value.store = context.store.state
  session.save(context)
}

• خطوط ۱۹ تا ۲۴ اضافه شده‌اند؛
• خط ۲۰: نام صفحه [context.route.name]، که قرار است نمایش داده شود و بنابراین صفحه‌ای است که کاربر در مرحله مسیریابی بعدی از آن آمده است، در مخزن قرار می‌گیرد. علاوه بر این، خواهیم دید که در مسیریابی برای سرور [nuxt]، سرور باید بداند که آیا مسیریابی فعلی از یک تغییر مسیر قبلی توسط سرور [nuxt] نشأت گرفته است یا خیر. در اینجا اینطور نیست، بنابراین ویژگی [serverRedirection] را روی [false] تنظیم می‌کنیم؛
• خطوط ۲۲–۲۴: وضعیت فروشگاه در جلسه [nuxt] قرار داده می‌شود (خط ۲۳)، سپس جلسه [nuxt] در یک کوکی ذخیره می‌شود (خط ۲۴)، که به نوبه خود در مرورگر کلاینت به عنوان [nuxt] ذخیره خواهد شد؛

بیایید به اسکریپت مسیریابی سرور [nuxt] بازگردیم:

/*eslint-disable no-console */
export default function(context) {
  //چه کسی این کد را اجرا می‌کند؟
  console.log('[middleware server], process.server', process.server, ', process.client=', process.client)

  //بازیابی برخی اطلاعات از فروشگاه [nuxt]
  const store = context.store
  // از کجا می‌آییم؟
  const from = store.state.from || 'nowhere'
  // به کجا می‌رویم؟
  const to = context.route.name
  // انحراف احتمالی
  let redirection = ''
  //مدیریت مسیریابی کامل شد
  let done = false

  //آیا ما در حال حاضر در حال تغییر مسیر از سرور [nuxt] هستیم؟
  if (store.state.serverRedirection) {
    // نیازی به اقدام نیست
    done = true
  }

  //آیا این بارگذاری مجدد صفحه است؟
  if (to === from) {
    // کاری برای انجام دادن نیست
    done = true
  }
  
  //در حال بررسی ناوبری روی سرور [nuxt]
  // بر اساس ناوبری سمت کلاینت در کامپوننت [navigation]

  //مواردی که جلسه PHP هنوز شروع نشده است
  if (!done && !store.state.jsonSessionStarted && to !== 'index') {
    //هدایت مجدد
    redirection = 'index'
    // وظیفه انجام شد
    done = true
  }

  // در مواردی که کاربر احراز هویت نشده است
  if (!done && store.state.jsonSessionStarted && !store.state.userAuthenticated && to !== 'authentification') {
    // هدایت مجدد
    redirection = from
    // وظیفه تکمیل شد
    done = true
  }

  // موردی که کاربر احراز هویت شده است
  if (!done && store.state.jsonSessionStarted && store.state.userAuthenticated && to !== 'get-admindata' && to !== 'fin-session') {
    // در همان صفحه باقی بمانید
    redirection = from
    // وظیفه انجام شد
    done = true
  }

  // موردی که در آن [adminData] به‌دست آمده است
  if (!done && store.state.jsonSessionStarted && store.state.userAuthenticated && store.state.adminData && to !== 'fin-session') {
    //کاربر همچنان در همان صفحه باقی می‌ماند
    redirection = from
    //کار تکمیل شد
    done = true
  }

  // تمام بررسی‌ها انجام شده است ---------------------
  // ارسال مجدد؟
  if (redirection) {
    // redirect در فروشگاه ثبت شده است
    store.commit('replace', { serverRedirection: true })
  } else {
    // بدون هدایت
    store.commit('replace', { serverRedirection: false, from: to })
  }
  //ذخیره فروشگاه در جلسه [nuxt]
  const session = context.app.$session()
  session.value.store = store.state
  session.save(context)
  //هر مسیریابی لازم انجام می‌شود
  if (redirection) {
    context.redirect({ name: redirection })
  }
}

• خطوط ۶–۹: مقدار [from] از فروشگاه روی سرور [nuxt] بازیابی می‌شود؛
• خط ۱۱: هدف مسیریابی فعلی ثبت می‌شود؛
• خط ۱۳: مسیریابی ممکن است منجر به هدایت مرورگر مشتری شود. [redirection] هدف این هدایت خواهد بود؛
• خط ۱۵: انتقال از [done] به [true] نشان می‌دهد که مسیریابی کامل شده است؛
• خطوط 17–21: ابتدا بررسی می‌کنیم که آیا مسیریابی فعلی ناشی از یک درخواست هدایت ارسال‌شده به مرورگر مشتری است. این اطلاعات در خصوصیت [serverRedirection] فروشگاه ذخیره می‌شود. اگر این خصوصیت روی true تنظیم شده باشد، به این معنی است که سرور [nuxt] در طول درخواست قبلی به سرور [nuxt]، یک هدایت به مرورگر مشتری ارسال کرده است. در این حالت، به مسیریابی نیازی نیست. در طول درخواست قبلی، روتر روی سرور [nuxt] تصمیم گرفته بود که مرورگر کلاینت باید به یک صفحه دیگر هدایت شود. این تصمیم نیازی به لغو شدن توسط یک تصمیم مسیریابی جدید ندارد؛
• خطوط ۲۳–۲۷: بررسی می‌کنیم که آیا مسیریابی فعلی، بارگذاری مجدد صفحه است یا خیر. اگر چنین باشد، اجازه می‌دهیم ادامه یابد؛
• از خط ۲۹ به بعد، از قواعد به‌کاررفته در کامپوننت [navigation] از کلاینت [nuxt] استفاده می‌شود (به پاراگراف قبلی مراجعه کنید)؛
• خطوط ۳۲–۳۸: این مورد را زمانی مدیریت می‌کند که جلسه jSON آغاز نشده باشد و مقصد مسیریابی صفحه [index] نباشد. در این حالت، مرورگر کلاینت به صفحه [index] هدایت می‌شود؛
• خطوط ۴۰–۴۶: این مورد زمانی را مدیریت می‌کند که جلسه jSON آغاز شده باشد، کاربر احراز هویت نشده باشد و هدف مسیریابی فعلی صفحه [authentification] نباشد. در این حالت، مسیریابی رد می‌شود و سیستم در وضعیت قبلی خود باقی می‌ماند؛
• خطوط ۴۸–۵۴: ما موردی را مدیریت می‌کنیم که جلسه jSON آغاز شده، کاربر احراز هویت شده و هدف مسیریابی فعلی نه صفحه [get-admindata] و نه صفحه [fin-session] است، که در این صورت تنها مقاصد ممکن هستند. در این حالت، مسیریابی درخواست‌شده رد می‌شود و کنترل به نقطه قبلی بازمی‌گردد؛
• خطوط 56–62: ما موردی را که [adminData] به دست آمده است، مدیریت می‌کنیم. در این حالت، تنها یک مقصد ممکن برای مسیریابی وجود دارد: صفحه [fin-session]. اگر این صفحه درخواست‌شده نبود، مسیریابی رد می‌شود و کنترل به نقطه قبلی بازمی‌گردد؛
• خطوط 64–72: اگر یک تغییر مسیر رخ داده باشد، این موضوع در مخزن سرور [nuxt] به عنوان [serverRedirection: true] ثبت می‌شود. توجه داشته باشید که هیچ مقداری به ویژگی [from] در مخزن اختصاص داده نمی‌شود. دلیل این امر آن است که یک هدایت (redirection) از مرورگر کلاینت انجام خواهد شد و ما دیده‌ایم که در این حالت، هیچ مسیریابی (routing) وجود ندارد (خطوط 17–20) و ویژگی [from] فروشگاه مورد استفاده قرار نمی‌گیرد؛
• خطوط ۶۶–۶۹: اگر مسیریابی وجود نداشته باشد، این مورد نیز در فروشگاه سرور به عنوان [nuxt]: [serverRedirection: false] ثبت می‌شود. علاوه بر این، مسیریابی فعلی صفحه [to] را نمایش می‌دهد که برای درخواست بعدی (از سمت کلاینت یا سرور [nuxt]) به صفحه قبلی تبدیل خواهد شد. به همین دلیل است که ما [from: to] را می‌نویسیم؛
• خطوط ۷۳–۷۶: مقدار store در جلسه [nuxt] ذخیره می‌شود که خود در یک کوکی ذخیره می‌گردد؛
• خطوط ۷۷–۸۰: اگر [redirection] خالی نباشد، به مرورگر دستور داده می‌شود که هدایت (redirect) کند. در غیر این صورت (که در اینجا نشان داده نشده است)، چرخهٔ عمر سرور [nuxt] ادامه خواهد یافت: صفحه [to] توسط سرور [nuxt] پردازش شده و با کوکی جلسه [nuxt] به مرورگر کلاینت [nuxt] ارسال می‌شود؛

مسیر‌یابی انتخاب‌شده در اینجا برای سرور [nuxt] دلخواهی است. می‌توانستیم یکی دیگر را انتخاب کنیم یا، همانطور که گفته شد، اصلاً از مسیر‌یابی استفاده نکنیم. مسیر‌یابی انتخاب‌شده در بالا این مزیت را دارد که همیشه برنامه را در وضعیت پایداری نگه می‌دارد، صرف‌نظر از اینکه کاربر کدام صفحه URL را درخواست می‌کند.

یک جنبه می‌تواند بهبود یابد زمانی که صفحه‌ای که در نهایت بارگذاری می‌شود، صفحهٔ اصلی باشد. دو سناریو وجود دارد:

• کاربر بارگذاری مجدد صفحه را (to===from) فعال کرده است؛
• بازنویسی‌ها به صفحهٔ اصلی وجود دارد (بازنویسی===از)؛

در هر دو حالت، صفحه اصلی دوباره با فراخوانی غیرهمزمان خود به سرور محاسبه مالیات اجرا خواهد شد. بیایید یک مثال بزنیم. اگر کاربر پس از احراز هویت، صفحه را دوباره بارگذاری کند (F5). در این حالت، در نمودار مسیریابی بالا، داریم: [to]=[from]=[authentification]. هیچ مسیریابی (redirection) وجود ندارد. صفحه [to=authentification] توسط سرور [nuxt] اجرا خواهد شد. اگر هیچ اقدامی انجام نشود، تابع [asyncData] دوباره اجرا می‌شود. این امر غیرضروری است زیرا احراز هویت قبلاً انجام شده است.

ما می‌توانیم با ایجاد یک تغییر جزئی در صفحه [authentification] این را بهبود بخشیم:

// داده‌های غیرهم‌زمان
  async asyncData(context) {
    // لاگ
    console.log('[authentification asyncData started]')
    // ما اگر صفحه قبلاً درخواست شده باشد، عملیات را دوباره انجام نمی‌دهیم
    if (process.server && context.store.state.userAuthenticated) {
      console.log('[authentification asyncData canceled]')
      return { result: '[succès]' }
    }
     // کلاینت [nuxt]
    if (process.client) {
      // شروع انتظار
      context.app.$eventBus().$emit('loading', true)
      // بدون خطا
      context.app.$eventBus().$emit('errorLoading', false)
    }
    try {
      // احراز هویت با سرور
...

• خطوط ۶–۹: اگر صفحه توسط سرور [nuxt] اجرا شود و فروشگاه نشان دهد که احراز هویت قبلاً انجام شده است، آنگاه نتیجه مورد نظر مستقیماً بازگردانده می‌شود (خط ۸)؛

ما همین کار را برای همه صفحات انجام می‌دهیم:

صفحه [index]:

// داده‌های ناهمزمان
  async asyncData(context) {
    // لاگ
    console.log('[index asyncData started]')
    // ما کارها را دو بار انجام نمی‌دهیم اگر صفحه قبلاً درخواست شده باشد
    if (process.server && context.store.state.jsonSessionStarted) {
      console.log('[index asyncData canceled]')
      return { result: '[succès]' }
    }
    try {
...

صفحه [get-admindata]

// داده‌های ناهمزمان
  async asyncData(context) {
    // لاگ
    console.log('[get-admindata asyncData started]')
    // ما کارها را دوبار انجام نمی‌دهیم اگر صفحه قبلاً درخواست شده باشد
    if (process.server && context.store.state.adminData) {
      console.log('[get-admindata asyncData canceled]')
      return { result: context.store.state.adminData }
    }
    // کلاینت
    if (process.client) {
      // شروع انتظار
      context.app.$eventBus().$emit('loading', true)
      // بدون خطا
      context.app.$eventBus().$emit('errorLoading', false)
    }
    try {
   ...  

صفحه [fin-session]

// داده‌های ناهمزمان
  async asyncData(context) {
    // لاگ
    console.log('[fin-session asyncData started]')
    // ما کارها را دو بار انجام نمی‌دهیم اگر صفحه قبلاً درخواست شده باشد
    if (process.server && context.store.state.jsonSessionStarted && !context.store.state.userAuthenticated) {
      console.log('[fin-session asyncData canceled]')
      return { result: "[succès]. La session jSON reste initialisée mais vous n'êtes plus authentifié(e)." }
    }
    // مورد مشتری [nuxt]
    if (process.client) {
      // شروع انتظار
      context.app.$eventBus().$emit('loading', true)
      // بدون خطا
      context.app.$eventBus().$emit('errorLoading', false)
    }
    try {
   

16.4. Exécution

برای اجرای این مثال، باید قبل از اجرا اطمینان حاصل کنید که کوکی جلسه [nuxt] و کوکی PHP را از مرورگری که کلاینت [nuxt] را اجرا می‌کند، حذف کنید تا کار را از ابتدا و با محیطی پاک آغاز کنید. در زیر مثالی با استفاده از مرورگر کروم آمده است:

16.5. Conclusion

روتینگ برای سرور [nuxt] پیچیده است زیرا لازم است تمام مقادیر URL را که کاربر ممکن است به صورت دستی وارد کند، پیش‌بینی کرد. این یک مثال کلاسیک است. یک برنامه کاربردی مانند [nuxt] برای استفاده به این روش طراحی نشده است. هنگامی که صفحه [index] توسط روتر روی سرور [nuxt] ارائه شد، درخواست‌های بعدی به سرور می‌توانستند به یک صفحه خطا هدایت شوند.

در مورد خاص مثال ما [nuxt-13]، مسیریابی برای سرور [nuxt] غیرضروری بود. رفتار پیش‌فرض (در عمل عدم مسیریابی) در مثال [nuxt-12] کاملاً به درستی کار می‌کرد.