ساخت یک اپلیکیشن React از صفر

مرحله 1: نصب یک ابزار ساخت

اولین مرحله نصب یک ابزار ساخت مانند vite، parcel، یا rsbuild است. این ابزارهای ساخت ویژگی‌هایی را برای بسته‌بندی و اجرای کد منبع، فراهم کردن سرور توسعه برای توسعه محلی و دستور ساخت برای استقرار اپلیکیشن خود بر روی سرور تولید فراهم می‌کنند.

Vite

Vite یک ابزار ساخت است که هدف آن فراهم کردن یک تجربه توسعه سریع‌تر و سبک‌تر برای پروژه‌های وب مدرن است.

Vite نظریات خود را دارد و با پیش‌فرض‌های معقول از ابتدا می‌آید. Vite دارای اکوسیستم غنی از افزونه‌ها برای پشتیبانی از بروزرسانی سریع، JSX، Babel/SWC، و سایر ویژگی‌های متداول است. برای شروع افزونه React یا افزونه React SWC و نمونه پروژه React SSR Vite را ببینید.

Vite قبلاً به عنوان ابزار ساخت در یکی از فریم‌ورک‌های توصیه شده ما استفاده می‌شود: React Router.

Parcel

Parcel یک تجربه توسعه فوق‌العاده خارج از جعبه را با معماری مقیاس‌پذیر ترکیب می‌کند که می‌تواند پروژه شما را از تازه شروع تا اپلیکیشن‌های تولید عظیم ببرد.

Parcel از بروزرسانی سریع، JSX، TypeScript، Flow، و استایل‌دهی خارج از جعبه پشتیبانی می‌کند. برای شروع دستور React Parcel را ببینید.

Rsbuild

Rsbuild یک ابزار ساخت با قدرت Rspack است که یک تجربه توسعه بدون مانع برای اپلیکیشن‌های React فراهم می‌کند. با پیش‌فرض‌های دقیق‌تر تنظیم شده و بهینه‌سازی‌های عملکرد آماده برای استفاده می‌آید.

Rsbuild دارای پشتیبانی داخلی برای ویژگی‌های React مانند بروزرسانی سریع، JSX، TypeScript، و استایل‌دهی است. برای شروع راهنمای React Rsbuild را ببینید.

مرحله 2: ساخت الگوهای اپلیکیشن مشترک

ابزارهای ساخت ذکر شده بالا با یک اپلیکیشن تک‌صفحه‌ای (SPA) فقط در سمت کلاینت شروع می‌شوند، اما هیچ راه‌حل بیشتری برای عملکرد مشترک مانند مسیریابی، واکشی داده، یا استایل‌دهی شامل نمی‌شوند.

اکوسیستم React شامل بسیاری از ابزارها برای این مسائل است. ما چند ابزار را که به طور گسترده‌ای به عنوان نقطه شروع استفاده می‌شوند فهرست کرده‌ایم، اما می‌توانید ابزارهای دیگری را انتخاب کنید اگر بهتر برای شما کار کنند.

مسیریابی

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

مسیریابها بخش اساسی از اپلیکیشن‌های مدرن هستند، و معمولاً با واکشی داده (شامل از پیش‌واکشی داده برای یک صفحه کامل برای بارگذاری سریع‌تر)، تقسیم کد (برای کاهش اندازه بسته کلاینت)، و روش‌های رندرینگ صفحه (برای تصمیم‌گیری درباره چگونگی تولید هر صفحه) یکپارچه می‌شوند.

ما توصیه می‌کنیم استفاده کنید:

• React Router
• Tanstack Router

واکشی داده

واکشی داده از یک سرور یا منبع داده دیگر بخشی کلیدی از اکثر اپلیکیشن‌ها است. انجام این کار به درستی نیاز به مدیریت حالت‌های بارگذاری، حالت‌های خطا، و ذخیره‌سازی در کش داده‌های واکشی شده دارد، که می‌تواند پیچیده باشد.

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

توجه داشته باشید که واکشی داده مستقیم در اجزا می‌تواند به دلیل آبشار‌های درخواست شبکه باعث زمان‌های بارگذاری کندتر شود، بنابراین ما توصیه می‌کنیم تا جای ممکن در محمل‌های مسیریاب یا بر روی سرور داده را از پیش‌واکشی کنید! این امکان را می‌دهد داده‌های صفحه به یکباره و هنگام نمایش صفحه واکشی شود.

اگر داده را از اکثر بک‌اند‌ها یا API‌های سبک REST‌ واکشی می‌کنید، ما توصیه می‌کنیم:

• React Query
• SWR
• RTK Query

اگر داده را از API GraphQL واکشی می‌کنید، ما توصیه می‌کنیم:

• Apollo
• Relay

تقسیم کد

تقسیم کد فرایند شکستن اپلیکیشن شما به بسته‌های کوچک‌تری است که می‌توانند بر اساس تقاضا بارگذاری شوند. اندازه کد اپلیکیشن با هر ویژگی جدید و وابستگی اضافی افزایش می‌یابد. اپلیکیشن‌ها می‌توانند بدلیل اینکه کل کد برای کل اپلیکیشن باید قبل از استفاده ارسال شود کند بارگذاری شوند. ذخیره‌سازی در کش، کاهش ویژگی‌ها/وابستگی‌ها، و انتقال برخی کدها برای اجرا بر روی سرور می‌تواند به کاهش بارگذاری کند کمک کند اما راه‌حل‌های ناقصی هستند که می‌توانند عملکرد را قربانی کنند اگر بیش‌ازحد استفاده شوند.

به طور مشابه، اگر شما برای تقسیم کد بر روی اپلیکیشن‌هایی که فریم‌ورک شما را استفاده می‌کنند تکیه کنید، ممکن است با شرایطی مواجه شوید که بارگذاری کندتر از اگر اصلاً تقسیم کد اتفاق نمی‌افتاد باشد. برای مثال، تنبل بارگذاری یک نمودار کد مورد نیاز برای رندرینگ نمودار را تأخیر می‌دهد، کد نمودار را از بقیه اپلیکیشن جدا می‌کند. Parcel از تقسیم کد با React.lazy پشتیبانی می‌کند. با این حال، اگر نمودار داده‌های خود را بعد از اینکه برای اولین بار رندر شد بارگذاری کند شما اکنون دو بار منتظر می‌مانید. این یک آبشار است: به جای واکشی داده نمودار و ارسال کد برای رندرینگ آن به طور همزمان، باید برای هر مرحله منتظر بمانید تا یکی پس از دیگری تکمیل شود.

تقسیم کد بر اساس مسیر، زمانی که با بسته‌بندی و واکشی داده یکپارچه شود، می‌تواند زمان بارگذاری اولیه اپلیکیشن و زمان رندرینگ بزرگ‌ترین محتوای قابل‌دیدی اپلیکیشن (Largest Contentful Paint) را کاهش دهد.

برای دستور‌العمل تقسیم کد، اسناد ابزار ساخت خود را ببینید:

• بهینه‌سازی‌های ساخت Vite
• تقسیم کد Parcel
• تقسیم کد Rsbuild

بهبود عملکرد اپلیکیشن

از آنجایی که ابزار ساخت انتخابی شما فقط از اپلیکیشن‌های تک‌صفحه‌ای (SPA) پشتیبانی می‌کند، باید سایر الگوهای رندرینگ مانند رندرینگ سمت سرور (SSR)، تولید سایت ایستا (SSG)، و/یا React Server Components (RSC) پیاده‌سازی کنید. حتی اگر در ابتدا به این ویژگی‌ها نیاز نداشته باشید، در آینده ممکن است مسیرهایی وجود داشته باشند که از SSR، SSG یا RSC سود ببرند.

• اپلیکیشن‌های تک‌صفحه‌ای (SPA) یک صفحه HTML را بارگذاری می‌کنند و صفحه را به طور پویا هنگام تعامل کاربر با اپلیکیشن به روزرسانی می‌کنند. SPA‌ها شروع شدن آسان‌تری دارند، اما می‌توانند زمان‌های بارگذاری اولیه کندتری داشته باشند. SPA‌ها معماری پیش‌فرض برای اکثر ابزارهای ساخت هستند.

• رندرینگ سمت سرور با جریان (SSR) یک صفحه را روی سرور رندر می‌کند و صفحه کاملاً رندر شده را به کلاینت ارسال می‌کند. SSR می‌تواند عملکرد را بهبود دهد، اما می‌تواند تنظیم و نگهداری آن نسبت به یک اپلیکیشن تک‌صفحه‌ای پیچیده‌تر باشد. با افزودن جریان، SSR می‌تواند بسیار پیچیده برای تنظیم و نگهداری باشد. راهنمای SSR Vite را ببینید.

• تولید سایت ایستا (SSG) فایل‌های HTML ایستا برای اپلیکیشن شما را در زمان ساخت تولید می‌کند. SSG می‌تواند عملکرد را بهبود دهد، اما می‌تواند تنظیم و نگهداری آن نسبت به رندرینگ سمت سرور پیچیده‌تر باشد. راهنمای SSG Vite را ببینید.

• React Server Components (RSC) به شما اجازه می‌دهد ترکیب اجزای زمان ساخت، فقط سرور، و تعاملی در یک درخت React واحد کنید. RSC می‌تواند عملکرد را بهبود دهد، اما در حال حاضر به تخصص عمیق برای تنظیم و نگهداری نیاز دارد. نمونه‌های RSC Parcel را ببینید.

استراتژی‌های رندرینگ شما باید با مسیریاب شما یکپارچه شوند تا اپلیکیشن‌هایی که با فریم‌ورک شما ساخته شده‌اند بتوانند استراتژی رندرینگ را در سطح هر مسیر انتخاب کنند. این امر امکان استراتژی‌های رندرینگ متفاوت را فراهم می‌کند بدون اینکه مجبور باشید کل اپلیکیشن خود را بازنویسی کنید. برای مثال، صفحه فرودی اپلیکیشن شما ممکن است از تولید ایستا (SSG) سود ببرد، در حالی که صفحه‌ای با یک خوراک محتوا ممکن است با رندرینگ سمت سرور بهترین عملکرد داشته باشد.

استفاده از استراتژی رندرینگ صحیح برای مسیرهای صحیح می‌تواند زمان را برای اولین بایت محتوا بارگذاری شده (Time to First Byte)، اولین قطعه محتوا رندر شده (First Contentful Paint)، و بزرگ‌ترین محتوای قابل‌دیدی اپلیکیشن رندر شده (Largest Contentful Paint) کاهش دهد.

و بیشتر…

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

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