این مقاله برگرفته از صحبتهای Alex Rickabaugh، یکی از اعضای تیم انگولار، درباره اجتناب از استفادهی effect و معرفی راهحلهای جایگزین در state management در انگولار است.
تا آنجایی که توانستم، سعی کردم بخاطر آشنایی با مفاهیم اولیه، از کلمات و واژههای انگلیسی، که روزانه با آنها درگیر هستیم، استفاده کنم که خوانندهها، ذهنشون درگیر معنی کلمات نشود.
مقدمه
در دنیای Reactive Programming در انگولار، استفاده از signal و computed signal به توسعهدهندگان اجازه میدهد تا به صورت مستقیم و با هماهنگی، تغییرات در UI را مدیریت کنند. effect ابزاری است که برای هماهنگسازی بین بخشهای Reactive (مثل signal و computed ) و دنیای Non-Reactive (مانند بهروزرسانی یک المان DOM) طراحی شده است. هرچند این ابزار قدرتمند و انعطافپذیر هست، اما استفاده از آن میتواند مشکلات و چالشهایی به همراه داشته باشد.
مشکلات استفاده از effect
ناهماهنگیهای زمانبندی: effect به صورت غیرهمزمان (asynchronously) اجرا میشود. این بدان معناست که وقتی signal مرتبط تغییر میکنند، effect ممکن است با تاخیر اجرا شود. به عنوان مثال، در سناریویی که یک کامپوننت select دارای یک items و یک selected Item انتخاب شده است، تغییر آیتمهای select ممکن است باعث شود که selected Item انتخاب شده (که مربوط به آیتمهای قبلی است) به صورت ناخواسته برای مدت زمان کوتاهی باقی بماند. این تأخیر میتواند باعث ایجاد Glitch in the Matrix شود که در آن UI اطلاعات نادرستی نمایش میدهد، حتی اگر دادههای اصلی تغییر کرده باشند.
ایجاد Single Source of Truth مستقل: وقتی هر کدام از بخشهای state، مثل items و selected Item انتخاب شده به صورت جداگانه مدیریت شوند و سپس نیاز به همگامسازی بین آنها ایجاد شود، Single Source of Truth به وجود میآید. این موضوع چالشهای زیادی را در مدیریت منطق و همگامسازی بهوجود میآورد.
پیچیدگیهای کدنویسی: بسیاری از توسعهدهندگان به دلیل قدرت effect ممکن است به سراغ آنها بروند، در حالی که در بسیاری از موارد ممکن است رفتار مورد انتظار را ایجاد نکند یا به عنوان یک "کد بد" تلقی شود. الزام به استفاده از effect برای همگامسازی حالت، اغلب نشانهای از مشکل در طراحی ساختار حالت است.
راهحلهای جایگزین پیشنهادی:
بایستی به جای استفاده از effect، ساختار حالت کامپوننتها به گونهای تغییر داده شود که آنچه باید همیشه sync باشد، در یک منبع واحد (Single Source of Truth) متمرکز گردد. در مثال توضیح داده شده در بالا، استفاده از computed signal به جای effect توصیه میشود.
به جای اینکه selected index انتخاب شده به عنوان یک signal مستقل در نظر گرفته شود، بهتر است این selected index به عنوان بخشی از یک state محاسبه شود. به عبارت دیگر، وقتی options تغییر میکند، state مربوط به انتخاب از نو ایجاد میشود؛ یعنی signal قبلی (برای selected index انتخاب شده) کنار گذاشته شده و یک signal جدید با مقدار پیشفرض (مثلاً -۱ برای هیچ انتخابی) ساخته میشود. این کار هم نه تنها هماهنگی بین دادهها را تضمین میکند، بلکه یک Single Source of Truth برای کامپوننت به وجود میآورد.
درسهای کلی در state management در انگولار:
تمرکز بر Single Source of Truth: ایده اصلی در Reactive programming این است که تمام states های مرتبط با UI از یک source واحد نشأت بگیرند. اگر بخواهیم از دو یا چند source مستقل استفاده کنیم و سپس آنها را sync کنیم، احتمال بروز خطا یا رفتار غیرمنتظره افزایش مییابد.
طراحی مجدد روابط داخل states: به جای تلاش برای synchronization states مجزا با effect، بهتر است ساختار دادهای خود را بازنگری کنید تا رابطه بین آنها به صورت طبیعی برقرار شود. اگر یک state (مثل selected index انتخاب شده) وابسته به state دیگری (مثل options) است، باید آن را به گونهای تعریف کرد که به صورت computed signal و در چارچوب همان source state واقعی بهروز شود.
استفادهی هوشمندانه از signal و computed signal: سیگنالهای انگولار این امکان را میدهند که تغییرات در دادهها به صورت خودکار بهروز شود و نیازی به مداخله مستقیم و دستی (مانند استفادهی مکرر از effect) نداشته باشید. این امر موجب کاهش بار فکری و افزایش پیشبینیپذیری در برنامههای کاربردی میشود.
هدف نهایی: استفاده از رویکردی متکی بر signal و computed signal باعث میشود که سیستم Reactive به صورت دقیق و بدون تاخیر، تغییرات وضعیت را مدیریت کند. از این رو، effect بیشتر برای کاربران پیشرفته مناسبند؛ در حالی که در اکثر موارد، راهحلهای سادهتر و بومیتری در دسترس هستند.
نتیجهگیری
اگرچه effect در انگولار، ابزارهایی قدرتمند برای هماهنگسازی بین دنیای Reactive و non Reactive ارائه میدهند، اما استفاده از آنها میتواند مشکلات timing و ناسازگاری در synchronization states ایجاد کند. به همین دلیل، توصیه میشود که به جای آن، ساختار حالت کامپوننتها به گونهای طراحی شود که وابستگیها به صورت computed signal و signal های تو در تو مدیریت شوند. این شیوه نه تنها وابستگیها را بهروش بهتری مدلسازی میکند، بلکه از بروز مشکلاتی مانند "Glitch in the Matrix" جلوگیری کرده و کدهای تمیزتر و قابل نگهداریتری به دست میدهد.
در نهایت به توسعهدهندگان انگولار یادآوری میشوذ، که همیشه باید قبل از تصمیمگیری برای استفاده از هر ابزاری، رابطهی بین دادههای خود را به دقت در نظر بگیرند و اگر امکان استفاده از یک single source وجود دارد، از آن بهره ببرند. این رویکرد در state management باعث میشود مشکلاتی مانند همگامسازی نادرست و تاخیر در بهروزرسانی دادهها به حداقل برسد.
این مقاله میتواند نقطهی شروع خوبی برای همه کسانی باشد که میخواهند درک بهتری از مفاهیم Reactive در انگولار داشته باشند و به دنبال راهکارهایی جایگزین بهینه برای state management در برنامههای خود هستند.
همچنین اگر به مباحث پیشرفتهتر، مانند نحوهی Input management و getters/setters در کنار Signals علاقهمندید، میتوانم در مقالات بعدی به این موضوعات بپردازم.
