فرادرسساخت Reducer تغییرناپذیر در ریداکس – از صفر تا صد
ریداکس (Redux) اساساً تنها یک سیستم اشتراک پیام‌رسانی یک‌طرفه محسوب می‌شود، اما با بهره گرفتن از آن می‌توانیم یک سیستم مدیریت حالت بسازیم که به طرز شگفت‌انگیزی مقیاس‌پذیر است. در این سیستم پیام‌رسانی می‌توانیم در رویدادها مشترک شویم، یعنی آن‌ها را مشاهده (Observe) کنیم یا به آن‌ها گوش (Listen) دهیم. این کار همانند فراخوانی یک تابع برای ایجاد یک درخواست به یک API است. نکته جالب‌تر این است که در این اشتراک می‌توان داده‌هایی نیز ارسال کرد. در این مقاله با روش ساخت Reducer تغییرناپذیر در ریداکس آشنا خواهیم شد.
در ریداکس در زمان اجرا (Runtime) اشتراک‌ها تنظیم و stroe-ها اعلان می‌شوند. گردش داده در ریداکس به این صورت است که ابتدا اکشن با یا بدون داده dispatch می‌شود. سپس مشترکان اطلاع‌رسانی می‌شوند و در نهایت داده‌ها در store سراسری تنظیم می‌شوند. همچنان که می‌بینید ریداکس کاملاً ماژولار و ساده است. فراموش نکنید که پیاده‌سازی شما از ریداکس باید پرتابل، تعویض‌پذیر و تا حدود زیادی قابل جداسازی از اپلیکیشن باشد. در ادامه این مقاله تلاش می‌کنیم یک پیاده‌سازی با این خصوصیات بسازیم.
در ریداکس با داده‌ها چه کنیم؟
اگر تاکنون به دنبال روش‌های مدیریت منطق در اپلیکیشن‌های ریداکس بوده باشید، احتمالاً با روش‌های بسیار گوناگونی مواجه شده‌اید. برخی می‌گویند که منطق باید در Reducer قرار گیرند، برخی محل آن را در اکشن می‌دانند و برخی دیگر نیز بر این باورند که نباید هیچ منطقی در ردیوسر یا اکشن قرار گیرد. ما نیز با این نظر اخیر موافق هستیم و معتقدیم نباید هیچ منطقی در ردیوسر یا اکشن‌ها وجود داشته باشد و باید کاملاً خالص و تابعی باشند.
پس منطق را کجا بگذاریم؟
برای این که راه‌حل‌های ما مقیاس‌پذیر و تمیز باشند دو گزینه وجود دارد:
- میان‌افزار منطقی برای ریداکس طراحی کنیم.
- منطق را خارج از ریداکس و در سرویس‌های منطقی قرار دهیم که داده‌ها را به اکشن‌ها ارسال می‌کنند.
زمانی که منطق خود را به خارج از ردیوسر منتقل کنید، می‌توانید شروع به بهینه‌سازی بکنید. بدین ترتیب می‌توان store را به صورت «تغییرناپذیر» (Immutable) و «خالص» (Pure) درآورد، یعنی هر چیزی که حالت دریافت می‌کند را باید تنظیم کند و هیچ عارضه جانبی یا فراخوانی تابع دیگری ندارد. البته امکان اعمال قالب‌بندی وجود دارد، اما تغییر در ساختار ممکن نیست. توجه داشته باشید که ساختار باید قابل پیش‌بینی و قطعی باشد و دلیل تعیین یک حالت اولیه هم جز این نیست.
با پیروی از این قواعد می‌توان از کتابخانه‌های تغییرناپذیری در ردیوسر صرفاً برای به‌روزرسانی مقادیری که در store تغییر یافته‌اند استفاده کرد. این امری بسیار مهم است، زیرا امکان بهینه‌سازی بیشتر را در بقیه بخش‌های اپلیکیشن فراهم می‌سازد.
برای نمونه در ری‌اکت PureComponents را داریم که بر مبنای تفاوت‌های حالت که به کامپوننت ارسال می‌شوند بهینه‌سازی می‌کند. اگر هر بار صرفاً یک state کاملاً کلون شده را در ردیوسر می‌خواستیم، استفاده از PureComponents دیگر توجیهی نداشت. در این حالت بدون استفاده از PureComponents امکان memoize هم به صورت صحیح پدید نمی‌آید. بدین ترتیب می‌بینید که استفاده از تغییرناپذیری یک زنجیره از مزایا را به همراه دارد.
اینک ردیوسر بدون بهینه‌سازی به صورت زیر است:
در مثال بهینه‌سازی نشده فوق، چند مشکل وجود دارد. همچنان که می‌بینید هیچ حالت اولیه تعیین نشده است، از طرفی حالت deepCloning شده که عوارض جانبی دارد. همچنین store به صورت شرطی به‌روزرسانی می‌شود. همچنان که پیش‌تر اشاره شد این عارضه‌های جانبی بر روی امکان بهینه‌سازی تأثیر می‌گذارند و موجب می‌شود که قابلیت پیش‌بینی‌پذیری داده‌ها کاهش یابد.
در ادامه مثالی از ردیوسر خالص/تغییرناپذیر را در وضعیت بهینه‌سازی شده می‌بینید:
در این نمونه بهینه‌سازی شده حجم کد کاهش یافته و اینک حالت پیش‌بینی‌پذیری بهتری دارد.
مزیت‌های این بهینه‌سازی به شرح زیر هستند:
- هیچ منطق یا عوارض جانبی وجود ندارد.
- مسئولیت منفردی تعریف شده است.
- همواره ساختار store یکسانی بازگشت می‌یابد.
- حالت اولیه برای افزایش انسجام/پیش‌بینی‌پذیری تعریف شده است.
- تغییرناپذیری کمک می‌کند صرفاً روی مقادیر تغییر یافته store عملیات کنیم.
- امکان کاربرد PureComponents و Memoizing فراهم شده است.
بدین ترتیب به پایان این مقاله می‌رسیم.
اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:
- مجموعه آموزش‌های جاوا اسکریپت
- مجموعه آموزش‌های برنامهنویسی
- استفاده از ریداکس در اپلیکیشن ری اکت — راهنمای کاربردی
- ریداکس (Redux) — مبانی مقدماتی
- مدیریت وب سوکت با Redux و Context — از صفر تا صد
==
