state management যত সাদামাটা রাখা যায়, তত ভালো

state management সাদামাটা রাখার দিকে আমার বেশ জোরালো ঝোঁক আছে। না বুঝে সহজ করা নয়, কম ইঞ্জিনিয়ারিং করাও নয়। সাদামাটা মানে কোনটা আসল তথ্য, সেটা লুকোনোর মতো অপ্রত্যাশিত জায়গা কম।

বড় Angular অ্যাপে কাজ কঠিন হয় যখন সহজ প্রশ্নের তাড়াতাড়ি উত্তর মেলে না। এই state-এর দায় কার, কে তা থেকে অন্য state বানায়, কে বদলাতে পারে, request ফেল করলে কী হয়, আর একটা সিদ্ধান্ত থেকে আর একটার মাঝখানে ব্যবহারকারী কী দেখেন?

ছোট view model, typed transition, স্পষ্ট loading আর error state, আর পুরো প্রোডাক্ট render না করেও পরীক্ষা করা যায় এমন feature boundary পছন্দ করি। RxJS শক্তিশালী। কিন্তু stream পড়া সাহসের পরীক্ষা হোক চাই না। signal কাজে লাগে, তবে দায়িত্ব স্পষ্ট করার প্রয়োজন সরায় না।

কোন state-এর জন্য কোন পদ্ধতি ভালো, তা ফিচারের ওপর। কিছু component-এর কাছে, কিছু route-এর কাছে, কিছু service-এর আড়ালে, কিছু store-এ থাকা উচিত। টুলটাই কথা নয়। স্মৃতি আর কুসংস্কারের ওপর না দাঁড়িয়ে দল state-এর জীবনচক্রটা বুঝতে পারছে কি না, সেটাই কথা।

template-এ state কেমন পড়ছে, সেটাও দেখি। view-কে বেশি ব্যাখ্যা করতে হলে user experience সম্ভবত ভুল layer-এ ছড়িয়ে আছে। derived state-এর নাম থাকুক। প্রোডাক্টের state স্পষ্ট হোক। edge case এতটা দেখা যাক, যাতে রিভিউয়ার খুঁজে পান।

state management সাদামাটা রাখা উচ্চাশার অভাব নয়। বিকেল পাঁচটায় কেউ দেখাননি এমন পথে গ্রাহকের কাজ আটকে গেলে যাঁকে debug করতে হবে, তাঁর প্রতি সম্মান।

লক্ষ্য জটিলতা উধাও করা নয়। দল নিরাপদে যেখানে তা নিয়ে কাজ করতে পারে, সেখানেই রাখা।