ظاهر Kushy در Next.JS
ﺯﻣﺎﻥ ﻣﻄﺎﻟﻌﻪ: 3 دقیقه

ظاهر Kushy در Next.JS

اخیرا تصمیم گرفتم که شروع به آزمایش Next.js، به عنوانی راهی برای پیاده‌سازی ظاهر React برای Kushy کنم. در حال حاضر، Kushy به جای این که یک برنامه جدا شامل API لاراول باشد، مستقیما بر روی لاراول اجرا می‌شود. من به دنبال راهی می‌گشتم که به React با Kushy وارد شود، اما پیدا کردن یک فریم‌وورک که سازگاری داشته باش، سخت است. همچنین نمی‌خواهم همه کارها (پیکربندی Webpack، routeها، تقسیم CSS و...) را از اول انجام دهم.

هدف این آزمایش، ساخت یک برنامه Next.js برای Kushy با استفاده از ای‌پی‌آی Kushy، و کشف این که برای ساخت عملکردهای پایه Kushy چه چیزی لازم بود، است.

مثال

می‌توانید این پروژه را بر روی Heroku ببینید، یا سورس کد آن را بر روی گیت‌هاب مشاهده کنید:

مشکلات

در هنگام کار با Next.js، به برخی مشکلات برخوردم. خوشبخاته این مشکلات زیاد نبودند.

Routing دینامیک (/posts/{slug})

Next.js این قابلیت را به طور پیشفرض ندارد. به همین دلیل، باید یک سرور Node.js را با استفاده از routeهای دینامیک خود (در این مورد، Express) بسازید.

در نهایت، برای آسان‌تر کردن این کار،‌ از این پلاگین استفاده کردم. البته در آینده فقط از ای‌پی‌آی Express استفاده خواهم کرد.

گسترش

Next.js می‌تواند مانند Jekyll یا هر مولد وبسایت استاتیک دیگری باشد. هر زمان که کد تغییر می‌کند، یک build process اجرا می‌کنید و سپس سرور را ری‌استارت می‌کنید.

npm run build
npm run start

این قابلیت، Next.js را برای چیزی مانند Heroku که پردازش‌ها را مدیریت می‌کند، بی‌نقص می‌کند. البته از آنجایی که Next.js هنگام خوشه‌دار بودن بهترین عملکرد را دارد، شاید گاهی مواقع اینطور نباشد.

ورود / احراز هویت کاربر

اگر می‌خواهید صفحاتی خاص را پشت یک احراز هویت برای ورود قفل کنید، Next.js هیچ قابلیت داخلی‌ای برای عملکرد routeهای حفاظت شده ندارد. خوشبختانه، با توجه به نحوه کارکرد Next.js در سمت سرور و سمت کاربر، این کار آنچنان هم سخت نبود.

برای وارد کردن یک کاربر، از یک API و OAuth2.0 استفاده کردم، و کاربر را به صفحه ورود آن API منتقل کردم. پس از این که کاربر وارد شد و برنامه او را قبول کرد، به صفحه‌ای از برنامه که از پیش تعیین شده است، بازگردانده می‌شود. این صفحه یک درخواست به API مورد نظر ارسال می‌کند، و آن API برای بار آخر با استفاده از یک نشان دسترسی یا JWT، به کاربر پاسخ می‌دهد.

در اینجا، جادوی Next.js به میان می‌آید. ما این نشانه را در یک کوکی در سمت سرور ذخیره می‌کنیم، که ما را قادر می‌سازد آن را از هر جایی دریافت کنیم. (سمت سرور یا سمت کاربر) وقتی که به آن نشانه نیاز داریم، آن را از headerهای سمت سرور parse می‌کنیم، (از متد getInitialProps() رد می‌کنیم) یا از یک کتابخانه مانند js-cookie برای گرفتن کوکی سمت کاربر استفاده می‌کنیم.

برای ساخت یک route محافظت شده، باید یک HOS (کامپوننت سطح بالا = High-order component) که در getInitialProps و چرخه componentDidMount() به دنبال کوکی مورد نظر می‌گردد، بسازید. اگر نشانه کوکی را پیدا کنید، این HOC صفحه کامپوننت را بارگذاری می‌کند. اما اگر نتواند کوکی مورد نظر را پیدا کند، کاربر را به یک صفحه عمومی (معمولا یک صفحه ورود)‌ منتقل می‌کند.

نتیجه گیری

درست به مانند هر فریم‌وورک دیگری، وقتی که بدانید چه می‌کنید، ساخت چیزی که می‌خواهید بی زحمت خواهد بود.

منبع

چه امتیازی برای این مقاله میدهید؟

خیلی بد
بد
متوسط
خوب
عالی
در انتظار ثبت رای

/@er79ka

دیدگاه و پرسش

برای ارسال دیدگاه لازم است وارد شده یا ثبت‌نام کنید ورود یا ثبت‌نام

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

در حال دریافت نظرات از سرور، لطفا منتظر بمانید