লেখা
Angular component-এর API-তেও প্রোডাক্টের ভাষা চাই
component-এর API পড়ে তার প্রোডাক্টের সিদ্ধান্তটা বোঝা যাক। শুধু সাজানোর সুইচের তালিকা যেন না হয়।
যে Angular component-এ ভরসা করি, সেগুলো প্রোডাক্টের ভাষায় কথা বলে। নিজের ভেতরের খুঁটিনাটি parent-কে সামলাতে বলে না। এমন শব্দ দেয় যা নিয়ে product manager, designer আর engineer একসঙ্গে আলোচনা করতে পারেন: selected, unavailable, pending review, destructive, empty, ready to submit।
component API-তে বেশির ভাগই দেখতে কেমন হবে তার flag হলে parent এমন আচরণের দায় নেয় যা তার নয়। এভাবেই সহজ একটা card-এ দশটা boolean আসে। আর একটা template-কে layout, state, permission আর প্রোডাক্টের লেখার মধ্যে সমঝোতা করতে হয়।
যে component-এর নিজের দায়িত্ব সম্পর্কে মত আছে, সেটা পছন্দ করি। review panel review state বুঝবে। workflow footer জানবে পরের action করা যায় কি না। status summary বুঝবে কোন অবস্থায় নজর দরকার। মানে বিরাট component বানানো নয়। প্রতিটা parent-কে একই নিয়ম আবার বানাতে না দিয়ে component-কে সত্যিকারের একটা কাজ দেওয়া।
দল সুযোগ দিলে Angular এভাবে কাজ করতে ভালো। input-এ প্রোডাক্টের state বলা যায়। template সিদ্ধান্তের মতো পড়া যায়। signal আর computed দিয়ে derived UI logic ফিচারের কাছে রাখা যায়। সব কিছু global abstraction-এ না তুলেও উদ্দেশ্য স্পষ্ট করার মতো কাঠামো framework-এ আছে।
ডিজাইন সিস্টেমেরও লাভ হয়। সেটা আয়তক্ষেত্রের জাদুঘর নয়, কাজ পৌঁছে দেওয়ার পরিকাঠামো। component-এ প্রোডাক্টের ব্যাকরণ থাকলে প্রতিটা feature branch-এ একটু আলাদা আচরণ বানাতে হয় না। দল দ্রুত এগোতে পারে।
আমার সহজ মাপটা কড়া: CSS, DOM-এর গঠন বা ইমপ্লিমেন্টেশনের খুঁটিনাটি না বলে component-এর public API বোঝাতে না পারলে, API-র কাজ সম্ভবত এখনও শেষ নয়।
ভালো component design-এ ইন্টারফেস বদলানো সহজ হয়, কারণ কোডে তখনই প্রোডাক্টের একই শব্দ ব্যবহার হচ্ছে।