বৃহৎ কম্পোনেন্ট লাইব্রেরির জন্য Vue 3 Composition API বনাম Options API

বড় অ্যাডমিন কম্পোনেন্ট লাইব্রেরিতে এই সিদ্ধান্ত কেন গুরুত্বপূর্ণ

একটি বড় অ্যাডমিন অ্যাপের কম্পোনেন্ট লাইব্রেরি একটি কয়েকটি বাটনের মার্কেটিং সাইট নয়। এটি ডজন-কয়েক (বা শত) বিল্ডিং ব্লক — ডাটা টেবিল যারা সর্টিং ও বাল্ক অ্যাকশন দেখে, ফিল্টার প্যানেল, ভ্যালিডেশন নিয়ম সহ ফর্ম, ড্রয়ার ও মডাল, কনফার্মেশন ফ্লো, এবং তারিখ পিকার বা পারমিশন গার্ডের মতো ছোট ইউটিলিটি।

এসব প্যাটার্ন বারবার আসে, তাই দলগুলো প্রায়ই ডেডলাইন মেটাতে কোড কপি ও টুইক করে। একটি টেবিলে কাস্টম ফিল্টার বার, অন্যটিতে একটু ভিন্ন, এবং দ্রুতই পাঁচটা “প্রায় একই” সংস্করণ হয়ে যায়। তখনই Composition API বনাম Options API প্রশ্নটা ব্যক্তিগত পছন্দের বাইরে গিয়ে পুরো লাইব্রেরির স্বাস্থ্যকে প্রভাবিত করে।

প্রথমেই যা বন্ধ হয়ে যায় তা হচ্ছে কনসিস্টেন্সি। UI কাজ করলেও বিহেভিয়ার ধীরে ধীরে ভিন্ন হয়ে যায়: একটি জায়গায় Escape চাপলে মডাল বন্ধ হয়, অন্য জায়গায় হয় না; একই ফিল্ড একটি পেজে blur-এ validate করে আর অন্যে submit-এ। এর পরে স্পিড কমে যায় কারণ প্রতিটি পরিবর্তনের জন্য near-duplicates খোঁজা লাগে। শেষে কনফিডেন্স কমে যায়: মানুষ রিফ্যাক্টর এড়ায় কারণ তারা predict করতে পারে না কী প্রভাব পড়বে।

একটি শেয়ার্ড লাইব্রেরিতে তিনটি ব্যবহারিক সিদ্ধান্ত সবচেয়ে বেশি গুরুত্বপূর্ণ:

• কোড পুনরায় ব্যবহার: কিভাবে tangled dependency ছাড়াই শেয়ার্ড লজিক প্যাকেজ করবেন।
• টেস্টিং: UI-ভিত্তিক fragility ছাড়া আচরণ নিশ্চিত করা কতটা সহজ।
• অনবোর্ডিং: নতুন কনট্রিবিউটার একটি কম্পোনেন্ট দ্রুত পড়ে নিরাপদে পরিবর্তন করতে পারবে কত দ্রুত।

একটি সহজ উদাহরণ: আপনার অ্যাডমিনে ২০টি লিস্ট পেজ আছে, এবং প্রোডাক্ট একটি নতুন “Saved filters” ফিচার চায়। যদি টেবিল, ফিল্টার, ও URL-sync লজিক ছড়িয়ে থাকে এবং inconsistent হয়, আপনি বা ধীরগতিতে শিপ করবেন বা বাগ নিয়ে শিপ করবেন। আপনি যেই API স্টাইল বেছে নেবেন তা নির্ধারণ করে দেবে ওই লজিক এক reusable জায়গায় থাকবে কি না, প্রতিটি স্ক্রিনে কিভাবে স্পষ্টভাবে ওয়্যার্ড করা আছে, এবং নতুন কেউ এটি কত সহজে এক্সটেন্ড করতে পারে।

আপনি যদি Vue 3 অ্যাডমিন অ্যাপ (অন্তর্ভুক্ত করে যেসব দল AppMaster-এর মত প্ল্যাটফর্মে Vue 3 ব্যবহার করে) তৈরি করেন, তখন এই সিদ্ধান্ত আগেভাগে নেওয়া অনেক মাসের রক্ষণাবেক্ষণ বাঁচাতে পারে।

দৈনন্দিন কোডে Options ও Composition কিভাবে আলাদা করে

ভেদ অনুভব করার দ্রুত উপায় হল একটি বড় অ্যাডমিন কম্পোনেন্ট খুলে জিজ্ঞেস করা: “এই একটি ফিচারের বিহেভিয়ার কোথায় বদলাবো?” একটি কম্পোনেন্ট লাইব্রেরিতে এই প্রশ্ন প্রতিদিনই উঠে।

Options API-তে কোড টাইপ অনুযায়ী গ্রুপ করা হয়: data রাজ্য, methods অ্যাকশন, computed ডেরাইভড ভ্যালু, এবং watch সাইড-এফেক্টের জন্য। ছোট কম্পোনেন্টে এই স্ট্রাকচার স্ক্যান করা সহজ। বড় টেবিল বা ফর্মে, এক ফিচারের লজিক (যেমন বাল্ক অ্যাকশন বা ফিল্ড ভ্যালিডেশন) প্রায়ই কয়েকটি ব্লকে ছড়িয়ে পড়ে। আপনি এটি পরিপাটি রাখতেই পারেন, কিন্তু তা করতে ডিসিপ্লিন ও কনসিস্টেন্ট নামকরণের প্রয়োজন হয় যাতে ফাইলের ভিতরে উড়োদৌড়ো করতে না হয়।

Composition API-তে কোড সাধারণত ফিচার অনুযায়ী গ্রুপ করা হয়। আপনি related state, ডেরাইভড ভ্যালু, সাইড-এফেক্ট, এবং হেলপারগুলো একসাথে সংজ্ঞায়িত করেন, এবং repeated লজিক composables-এ টেনে নিতে পারেন। অ্যাডমিন-স্টাইল লাইব্রেরিতে এটি প্রায়ই মানুষের ভাবনার সাথে মিলে: “ফিল্টারিং-এর সবকিছু এখানে,” “রো সিলেকশনের সবকিছু এখানে।” এটা একই ধরনের কম্পোনেন্টে duplication কমাতে সাহায্য করে — যেমন একাধিক টেবিলে usePagination পুনরায় ব্যবহার করা যায়।

দৈনন্দিন বড় পার্থক্যগুলোর মধ্যে একটি হচ্ছে কিভাবে নির্ভরতা (dependencies) দেখা যায়:

• Options API কিছুটা implicit লাগে: একটি method this.user, this.filters, এবং this.loading-এর উপর নির্ভর করতে পারে, এবং আপনি সেটি পড়ে ভিতরে গিয়ে বুঝবেন।
• Composition API বেশী explicit হয়: যখন একটি ফাংশন filters ও loading বন্ধ করে রাখে, আপনি কাছেই ঐ ভ্যারিয়েবলগুলোকে দেখতে পান, এবং প্রয়োজনে helper ফাংশনে এগুলো পাস করতে পারেন।

ট্রেডঅফ হল Composition API যদি সংগঠিত না করা হয় (সবকিছু setup()-এ ঢেলে দেওয়া) তবে শুনশান বা noisy হয়ে উঠতে পারে।

একটি ব্যবহারিক রুল অফ থাম্ব:

• যখন কম্পোনেন্টগুলো প্রধানত প্রেজেন্টেশনাল এবং লজিক হালকা, তখন Options API বেছে নিন।
• যখন কম্পোনেন্টগুলোতে একাধিক ফিচার আছে এবং লাইব্রেরি জুড়ে শেয়ার্ড নিয়ম আছে, তখন Composition API বেছে নিন।
• Composition API বেছে নিলে, কোডকে ফিচার অনুযায়ী গ্রুপ করার জন্য একটি সহজ লেআউটে একমত হোন (সব refs আগে রাখার মতো নয়)।
• Options API বেছে নিলে, নামকরণ জোরদার করুন এবং সংক্ষিপ্ত মন্তব্য ও কনসিস্টেন্ট method নাম দিয়ে related লজিক একসাথে রাখুন।

দুটোই কাজ করতে পারে। মূল বিষয় হল এমন একটি সংগঠন বেছে নেওয়া যা পরবর্তী পরিবর্তনটিকে obvious করে তোলে, clever নয়।

কোড পুনরায় ব্যবহার: কী পরিষ্কারভাবে স্কেল হয় ও কী জটিল হয়

অ্যাডমিন-স্টাইল অ্যাপগুলোতে reuse একটা অপশন নয়। আপনি অনবরত একই আচরণ পুনরাবৃত্তি করেন এবং ছোট অসামঞ্জস্যগুলো বাগ ও সাপোর্ট টিকিটে পরিণত হয়।

অনেক reuse-এর চাহিদা কয়েকটি নিয়মিত বালতিতে পড়ে: ব্যাকএন্ডের সাথে মেলে এমন sorting/filtering/pagination, ফর্ম ভ্যালিডেশন ও এরর ম্যাপিং, পারমিশন চেক ও UI গেটিং, কোয়েরি সিঙ্কিং (URL params, saved views, default filters), এবং সিলেকশন নিয়ম সহ বাল্ক অ্যাকশন।

Options API reuse: শক্তিশালী, কিন্তু complexity লুকোয়ানো সহজ

Options API-তে reuse প্রায়ই mixins, extends, বা প্লাগইন দিয়ে শুরু হয়।

Mixins দ্রুত, কিন্তু তারা বেশ ভালোভাবে স্কেল করে না কারণ তারা method বা computed কোথা থেকে এসেছে লুকিয়ে রাখে। দুটি mixin একই method নাম নিয়ে টক্কর করতে পারে, এবং তখন আপনি এমন আচরণ ডিবাগ করছেন যা কম্পোনেন্ট ফাইলে দৃশ্যমান নেই।

extends mixinsের চাইতে পরিষ্কার লাগতে পারে, কিন্তু এটি এখনও ইনহেরিট্যান্স ধাঁধায় নিয়ে আসে যেখানে আপনাকে বোঝার জন্য একাধিক ফাইল পড়তে হয়। প্লাগইনগুলো অ্যাপ-লেভেল কনসার্ন (গ্লোবাল ডিরেক্টিভ, শেয়ার্ড সার্ভিস) এর জন্য ভালো, কিন্তু তারা সেই জায়গা নয় যেখানে স্ক্রিন অনুযায়ী ব্যবসায়িক নিয়ম থাকা উচিত।

গয়লা মুহূর্ত সাধারণত আসে যখন reuse implicit হয়ে যায়। নতুন কনট্রিবিউটার “এই ডেটা কোথা থেকে আসে?” উত্তর জানার জন্য পুরো কোডবেস সার্চ করতে হয়।

Composition API reuse: composables যা explicit থাকে

Composition API reuse সাধারণত composables-কে কেন্দ্র করে গড়ে ওঠে: ছোট ফাংশন যা refs, computed ভ্যালু, এবং হ্যান্ডলার রিটার্ন করে। বড় জয় হল যে reuse কম্পোনেন্টের প্রারম্ভেই দৃশ্যমান হয়, এবং আপনি প্যারামিটার পাস করতে পারেন নির্ভরতার জন্য, লুকানো component context-এর উপর নির্ভর না করে।

উদাহরণস্বরূপ, একটি usePagination composable ডিফল্ট গ্রহণ করতে পারে এবং পরিবর্তনগুলি একটি কনসিস্টেন্ট শেপে ইমিট করতে পারে, আর usePermissions বর্তমান রোল ও একটি ফিচার নাম গ্রহণ করতে পারে। তখন সিদ্ধান্তটা সিনট্যাক্সের চাইতে বেশি হয়: আপনার লাইব্রেরি explicit wiring কে পছন্দ করে নাকি implicit inheritance কে।

পুনরায় ব্যবহার predictably রাখতে, প্রতিটি reusable ইউনিটকে একটি খুব ছোট API হিসেবে আচরণ করতে বলুন: স্পষ্ট নাম দিন, ইনপুট ও আউটপুট সংজ্ঞায়িত করুন, এবং একটিমাত্র দায়িত্ব রাখুন। যদি একটি composable পেজিনেশন, ক্যাশিং, পারমিশন, এবং নোটিফিকেশন সব হ্যান্ডেল করতে শুরু করে, তা বিভক্ত করুন। পরে একটি টুকরা বদলানো সহজ হয় বিরাম ছাড়া সব ভেঙে ফেলাই।

ব্যথাহীনভাবে পুনরায় ব্যবহারযোগ্য ফর্ম ও টেবিল কম্পোনেন্ট নির্মাণ

অ্যাডমিন-স্টাইল অ্যাপগুলোতে, ফর্ম ও টেবিল হল এমন জায়গা যেখানে একটি কম্পোনেন্ট লাইব্রেরি বা তো উপকার দেয় বা জটিল ল্যাবিরিন্থে পরিণত করে। দুইটি API-ই কাজ করতে পারে; পার্থক্য হল আপনি কীভাবে dirty state, এরর ম্যাপিং, এবং submit ফ্লো মতো শেয়ার্ড আচরণ প্যাকেজ করবেন যাতে প্রতিটি কম্পোনেন্ট “বিশেষ” না লাগে।

শেয়ার্ড ফর্ম লজিকের জন্য, Options API সাধারণত আপনাকে mixins বা শেয়ার্ড হেল্পারের দিকে ঠেলে দেয়। Mixins প্রথমদিকে সুবিধাজনক মনে হতে পারে, কিন্তু পরে এটি উত্তর দেওয়া কঠিন করে দেয়: “এই ফিল্ডের এরর কোথা থেকে আসে?” বা “কেন submit disabled আছে?”

Composition API এই ধরনের reuse-কে দৃশ্যমান করে কারণ আপনি লজিক composables-এ সরিয়ে নিতে পারেন (উদাহরণ: useDirtyState, useFormErrors, useSubmitFlow) এবং দেখতে পারেন ঠিক কোন লজিক একটি ফর্ম কম্পোনেন্টে ইনজেক্ট করা হচ্ছে। বড় লাইব্রেরিতে এই স্পষ্টতা কয়েক লাইনের সঞ্চয়কর্তার চাইতে বেশি মূল্যবান।

কোম্পোনেন্ট API স্টেবল রাখার ব্যবহারিক উপায় হল আপনার পাবলিক সারফেসকে একটি কনট্রাক্ট হিসেবে বিবেচনা করা: props, emits, এবং slots অল্প বদলাতে হবে, এমন কৌশল গ্রহণ করুন। এই কনট্রাক্ট দুটো স্টাইলেই একইভাবে দেখা যায়, কিন্তু Composition API প্রায়ই রিফ্যাক্টরগুলোকে নিরাপদ করে তোলে কারণ আপনি একবারে একটি composable বদলে টেমপ্লেট API ছুঁড়ে না।

বর্ধিত হওয়ার সাথে সাথে সাধারণত যে প্যাটার্নগুলো ঠিক থাকে:

• একক কাজ ভালভাবে করা base components তৈরি করুন (BaseInput, BaseSelect, BaseTable) এবং সেগুলোকে feature কম্পোনেন্টে কম্পোজ করুন।
• লেআউট ফ্লেক্সিবিলিটির জন্য অনেক প্রপ যোগ করার পরিবর্তে slots-কে প্রাধান্য দিন (actions area, empty states, cell rendering)।
• ইভেন্টগুলোকে অল্প-নর্মালাইজ করুন (উদাহরণ: update:modelValue, submit, rowClick) যাতে অ্যাপগুলো ইন্টার্নাল ডিটেইলসের উপর নির্ভর না করে।
• ভ্যালিডেশন ও ফরম্যাটিং ইনপুটের কাছে রাখুন, কিন্তু ব্যবসায়িক নিয়ম বাইরে রাখুন (composables বা parent containers-এ)।

ওভার-অ্যাবস্ট্র্যাকশন সাধারণত ফাঁদ। একটি “super form” কম্পোনেন্ট যা প্রতিটি ফিল্ড টাইপ, প্রতিটি ভ্যালিডেশন নিয়ম, এবং প্রতিটি লেআউট অপশন হ্যান্ডেল করে অনেক সময় plain Vue-র চেয়েও ব্যবহার করতে কঠিন হয়ে ওঠে। ভাল নিয়ম হল: যদি একটি base component বহু prop ছাড়া দলের সব চাহিদা কভার করার জন্য বেশি প্রপ দরকার হয়, সেটাকে হয় দুটো কম্পোনেন্ট করা উচিত।

কখনও কখনও ডুপ্লিকেশনই সঠিক সিদ্ধান্ত। যদি মাত্র একটি স্ক্রিনেই অদ্ভুত টেবিল হেডার দরকার যা মাল্টি-রো গ্রুপিং করে, ছোট অংশ কপি করে লোকাল রাখুন। ক্লেভার অ্যাবস্ট্র্যাকশনগুলোর দীর্ঘ রক্ষণাবেক্ষণ টেইল থাকে, বিশেষ করে যখন নতুন কনট্রিবিউটরদের যোগ দেওয়া হয় এবং তারা “নর্মাল” কম্পোনেন্ট ও ফ্রেমওয়ার্ক-ভিত্তিক কম্পোনেন্টের মধ্যে পার্থক্য বোঝার চেষ্টা করে।

আপনি যদি Composition ও Options-এর মধ্যে সিদ্ধান্ত নিচ্ছেন বড় ফর্ম ও টেবিল লাইব্রেরির জন্য, প্রথমে ডেটা ফ্লোর পাঠযোগ্যতার ওপর অপ্টিমাইজ করুন। পুনরায় ব্যবহার ভাল, কিন্তু যখন তা ইউজার অ্যাকশন থেকে ইমিট হওয়া ইভেন্টের পথ লুকায় তখন সেটি খারাপ।

টেস্টিং প্রভাব: কী পরীক্ষা করা সহজ হয়

একটি কম্পোনেন্ট লাইব্রেরিতে, টেস্টগুলো সাধারণত তিনটি বালতিতে পড়ে: পিউর লজিক (ফরম্যাটিং, ভ্যালিডেশন, ফিল্টারিং), রেন্ডারিং (কোন অবস্থা দেখায় কি), এবং ইন্টারঅ্যাকশন (ক্লিক, ইনপুট, কীবোর্ড, ইমিট)। আপনি যে API স্টাইল বেছে নেবেন তা প্রথম বালটিকে কতবার DOM-মাউন্ট ছাড়া পরীক্ষা করা যায় তা বদলে দেয়।

Options API টেস্টগুলো প্রায়ই দেখতে এমন হয়: “কম্পোনেন্ট মাউন্ট করুন, ইনস্ট্যান্স স্টেট টিউন করুন, DOM assert করুন।” এটা কাজ করে, কিন্তু এটি বড় টেস্টকে উৎসাহিত করতে পারে কারণ লজিক methods, computed, watch, এবং লাইফসাইকেল হুকগুলোর সাথে মিশে থাকে। যখন কিছু ফেল করে, আপনি সময়ই নষ্ট করেন বুঝতে যে এটা watcher timing, lifecycle side effect, না লজিকের ত্রুটি।

Options API সাধারণত এদের জন্য সোজা লাগে:

• লাইফসাইকেল অর্ডারের উপর নির্ভরকারী ইউজার ফ্লো (mount-এ fetch, route change-এ reset)
• watcher-চালিত আচরণ (auto-save, query syncing)
• কম্পোনেন্ট methods থেকে ইভেন্ট ইমিশন (save(), reset(), applyFilter())

Composition API ভারসাম্য বদলায়। যদি আপনি লজিক composables-এ সরান, আপনি সেই লজিককে সাধারণ ফাংশনের মতো ইউনিট টেস্ট করতে পারবেন, ছোট ইনপুট ও স্পষ্ট আউটপুট দিয়ে। এতে “মাউন্ট করে ক্লিক” টেস্টের প্রয়োজন কমে এবং ফেলিওর লোকাল হয়ে যায়। নির্ভরতাগুলো নিয়ন্ত্রণও সহজ হয়: গ্লোবাল মক করার বদলে আপনি composable-এ একটি dependency (যেমন fetch ফাংশন, date formatter, বা permission checker) পাস করবেন।

কনক্রিট উদাহরণ: একটি reusable AdminTable যার মধ্যে sorting, pagination, এবং selected rows আছে। Composition API-এ selection লজিক useRowSelection()-এ থাকতে পারে এবং টেবিল রেন্ডার না করেই তা টেস্ট করা যায় (toggle, clear, select all, পেজ জুড়ে preserve)। তারপর আপনি কম্পোনেন্ট টেস্টগুলো ছোট রাখেন যাতে টেমপ্লেট বাটন, চেকবক্স, এবং ইমিট করা ইভেন্টগুলো সঠিকভাবে ওয়্যার্ড হয়েছে কিনা কনফার্ম করে।

টেস্টগুলো ছোট ও পড়তে সহজ রাখতে (যে স্টাইলই হোক না কেন), UI ও লজিকের মধ্যে একটি স্পষ্ট সিম রাখুন:

• ব্যবসায়িক নিয়ম পিউর ফাংশন বা composables-এ রাখুন, watchers-এ নয়।
• সাইড-এফেক্ট (fetch, storage, timer) ইনজেক্টেড ডিপেনডেন্সির পেছনে রাখুন।
• প্রতিটি কম্পোনেন্টে কয়েকটি ফোকাসড ইন্টিগ্রেশন টেস্ট রাখুন, একটি বিশাল “সবকিছু” টেস্ট নয়।
• লাইব্রেরি জুড়ে স্টেট ও ইভেন্টগুলো কনসিস্টেন্ট নাম দিন (টেস্ট সেটআপ সহজ হয়)।
• লুকানো কাপলিং এড়ান (যেমন method A watcher B চালানোর উপর নির্ভর করলে সমস্যা হয়)।

যদি আপনার লক্ষ্য এমন একটি স্টাইল সিদ্ধান্ত হওয়া যা টেস্ট স্থিতিশীলতা বাড়ায়, তাহলে lifecycle-চালিত আচরণ কমিয়ে আরও আইসোলেটেড লজিক ইউনিট তৈরির দিকে এগোন।

নতুন কনট্রিবিউটার অনবোর্ডিং: মানুষ কত দ্রুত কার্যকর হয়

বড় অ্যাডমিন-স্টাইল কম্পোনেন্ট লাইব্রেরিতে, অনবোর্ডিং Vue শেখানোর চেয়ে বেশি বিষয় এটি: মানুষ কোথায় খুঁজবে, একেই কিভাবে করা হয় তার convention কী, এবং তারা কীভাবে নিরাপদে পরিবর্তন করবে তা শেখানো। ধীরতার প্রধান কারণ তিনটি: ন্যাভিগেশন (লজিক কোথায়?), কনভেনশন (এখানে আমরা কীভাবে করি?), এবং কনফিডেন্স (আমি কীভাবে এক বদল করব যা পাঁচটি স্ক্রিন ভাঙবে না?)।

Options API-তে, নবাগতরা প্রথম দিনেই দ্রুত কাজ শুরু করতে পারে কারণ স্ট্রাকচার পরিচিত: props, data, computed, methods, watchers। ট্রেডঅফ হল বাস্তব আচরণ প্রায়ই ছড়িয়ে থাকে। “সার্ভার-সাইড ফিল্টারিং” মতো একটি ফিচার watcher, computed এবং দুইটি method-এ বিভক্ত থাকতে পারে, প্লাস একটি mixin। মানুষ প্রতিটি ব্লক পড়তে পারে, কিন্তু তারা গল্প জোড়া দেবার সময় কাটায়।

Composition API-তে অনবোর্ডিংয়ের জয় হল সম্পর্কিত লজিক একসাথে থাকতে পারে: state, সাইড-এফেক্ট, এবং হেলপার এক জায়গায়। ব্যয় হচ্ছে composable-এর দক্ষতা — নতুন কনট্রিবিউটারগুলোকে useTableState()-এর মত প্যাটার্নসমূহ ও কিভাবে reactive ভ্যালুগুলো একাধিক composable দিয়ে ফ্লো করে তা বোঝাতে হবে। স্পষ্ট সীমা না থাকলে এটা ফাইলের মধ্যে ঝাঁপ দেওয়ার মত মনে হতে পারে।

কয়েকটি কনভেনশন বেশির ভাগ প্রশ্ন সরিয়ে দেয়, যেই স্টাইলই হোক:

• একটি পূর্বানুমানযোগ্য নির্মাণ রাখুন: components/, composables/, types/, tests/।
• একটি নামকরণ প্যাটার্ন বেছে নিন ও মেনে চলুন (উদা: useX, XTable, XForm).
• সংক্ষিপ্ত docblocks যোগ করুন: কম্পোনেন্ট কী করে, মূল props, এবং প্রধান ইভেন্ট।
• একটি “escape hatch” নিয়ম নির্ধারণ করুন (কখন নতুন composable/হেল্পার যোগ করা ঠিক)।
• একটি ছোট “golden” কম্পোনেন্ট রাখুন যা পছন্দসই প্যাটার্ন দেখায়।

উদাহরণ: যদি আপনার দল একটি Vue 3 অ্যাডমিন প্যানেল জেনারেট করে এবং তারপর তা কাস্টমাইজ করে (উদাহরণস্বরূপ, AppMaster-এ তৈরি ও ডেভেলপাররা এক্সটেন্ড করে), অনবোর্ডিং অনেক উন্নত হয় যখন টেবিল আচরণ (sorting, filters, pagination) সংশোধন করার একটি স্পষ্ট জায়গা থাকে এবং UI ওয়্যারিং (slots, column renderers, row actions) সংশোধনের আরেকটি স্পষ্ট জায়গা থাকে। এই স্পষ্টতা API-র চেয়ে বেশি বিষয়।

ধাপে ধাপে: একটি স্টাইল বেছে নেওয়া ও নিরাপদভাবে প্রবর্তন

বড় অ্যাডমিন UI লাইব্রেরির জন্য, সবচেয়ে নিরাপদ উপায় হলো একটি ভালো-বাউন্ডেড ফিচার নিয়ে শুরু করা এবং এটাকে একটি পাইলট হিসেবে দেখা, পুরো রিরাইট না করে।

একটি একক মডিউল বেছে নিন যার আচরণ স্পষ্ট ও উচ্চ reuse আছে, যেমন টেবিল ফিল্টারিং বা ফর্ম ভ্যালিডেশন। কোড চুইতে যাওয়ার আগে লিখে নিন এখন এটা কী করে: ইনপুট (props, query params, user actions), আউটপুট (events, emits, URL পরিবর্তন), এবং এজ কেস (empty state, reset, server errors)।

পরবর্তী ধাপে সীমানা নির্ধারণ করুন। কি অবশ্যই কম্পোনেন্টের ভিতরে থাকা উচিত (রেন্ডারিং, DOM ইভেন্ট, অ্যাক্সেসিবিলিটি) এবং কি শেয়ার্ড কোডে যেতে পারে (ফিল্টার পার্সিং, ডিবাউন্সিং, API প্যারাম গঠন, ডিফল্ট স্টেট)। লাইব্রেরির ভুল সাধারণত এখানে হয়: যদি আপনি UI সিদ্ধান্ত শেয়ার্ড কোডে সরিয়ে দেন, reuse করা কঠিন হয়ে যায়।

একটি ব্যবহারিক রোলআউট প্ল্যান:

• একটি কম্পোনেন্ট বেছে নিন যা প্যাটার্নটি স্পষ্টভাবে দেখায় এবং একাধিক স্ক্রিনে ব্যবহার হয়।
• একটি শেয়ার্ড ইউনিট (composable বা plain helper) বের করুন যার API ছোট ও explicit।
• প্রথমে ঐ ইউনিটের জন্য একটি ফোকাসড টেস্ট লিখুন, রিয়েল অ্যাডমিন সিনারিও ব্যবহার করে।
• নতুন ইউনিট ব্যবহার করে চয়ন করা কম্পোনেন্টটি end-to-end রিফ্যাক্টর করুন।
• একই প্যাটার্ন আরেকটি কম্পোনেন্টে প্রয়োগ করে নিশ্চিত করুন এটা স্কেল করে।

শেয়ার্ড API-কে boring ও obvious রাখুন। উদাহরণ: একটি useTableFilters() composable প্রারম্ভিক filters গ্রহণ করতে পারে এবং filters, apply(), reset(), এবং toRequestParams() এক্সপোজ করে। গ্লোবাল স্টেট থেকে “ম্যাজিক” পড়া এড়ান যদি না সেটি আপনার অ্যাপে ইতিমধ্যে কঠোর নিয়ম।

পাইলটের পরে, একটি সংক্ষিপ্ত অভ্যন্তরীণ গাইডলাইন প্রকাশ করুন যার একটি উদাহরণ কপি করে কনট্রিবিউটাররা ব্যবহার করতে পারে। একটি পরিষ্কার নিয়ম দীর্ঘ ডকুমেন্টের চেয়েও কার্যকর—for example: “সব টেবিল ফিল্টারিং লজিক composable-এ থাকে; কম্পোনেন্ট কেবল UI কন্ট্রোল বাইন্ড করে এবং apply() কল করে।”

প্রসারণের আগে একটি সরল ডেফিনিশন অফ ডন ব্যবহার করুন:

• নতুন কোড দুইটি আলাদা কম্পোনেন্টে একইরকম পড়ে।
• টেস্টগুলো শেয়ার্ড লজিক কভার করে UI মাউন্ট ছাড়া।
• একটি নতুন কনট্রিবিউটার একটি ফিল্টার নিয়ম বদলাতে পারে unrelated ফাইল না ছুঁড়েই।

আপনার দল যদি AppMaster-এর মত একটি নো-কোড টুল দিয়ে অ্যাডমিন পোর্টালও তৈরি করে, আপনি একই পাইলট মানসিকতা সেখানে ব্যবহার করতে পারেন: একটি ওয়ার্কফ্লো বেছে নিন (যেমন approvals), আচরণগুলো নির্ধারণ করুন, তারপর pattern স্ট্যান্ডার্ড করে স্কেল করুন।

বড় লাইব্রেরিতে সাধারণ ভুল ও ফাঁদ

বড় কম্পোনেন্ট লাইব্রেরির প্রধান সমস্যা সাধারণত সিনট্যাক্স সম্পর্কিত না। তারা ছোট লোকাল সিদ্ধান্ত থেকে আসে যা ধীরে ধীরে জমে reuse, টেস্টিং, এবং রক্ষণাবেক্ষণ কঠিন করে দেয়।

একটি সাধারণ ফাঁদ হলো প্যাটার্নগুলো এলোমেলোভাবে মিশিয়ে ফেলা। যদি লাইব্রেরির অর্ধেক Options API এবং অন্য অর্ধেক Composition API ব্যবহার করে কোন নিয়ম না থাকে, প্রতিটি নতুন কম্পোনেন্ট একটি স্টাইল বিতর্ক হয়ে যায়। এছাড়া একই সমস্যা একই রকমভাবে লিখতে গিয়ে নকল সমাধানও জন্মায়। যদি আপনি দুইটিকে আলাউ করেন, সেক্ষেত্রে একটি পরিষ্কার নীতি লিখে রাখুন: নতুন কম্পোনেন্টগুলো এক স্টাইল ব্যবহার করবে, লেগ্যাসি কেবল প্রয়োজন হলে স্পর্শ হবে, এবং শেয়ার্ড লজিক এক সম্মত জায়গায় রাখা হবে।

আরেকটি ফাঁদ হলো “god composable।” এটা সাধারণত একটি সহায়ক useAdminPage() বা useTable() হিসেবে শুরু হয় এবং ধীরে ধীরে রাউটিং, fetching, ক্যাশিং, সিলেকশন, ডায়ালগ, টোস্ট, এবং পারমিশন সব গ্রহণ করে ফেলে। এটি টেস্ট করা কঠিন করে কারণ এক কল অনেক সাইড-এফেক্ট ট্রিগার করে। এটি পুনরায় ব্যবহারও কঠিন করে কারণ প্রতিটি স্ক্রিনের মাত্র ৩০% দরকার হলেও ১০০% জটিলতা বহন করতে হয়।

Watchers আরেক ঝুঁকি। কিছু আনসিঙ্ক ডেটা ও ডিবাউন্সড ইনপুটের সঙ্গে টাইমিং বাগ দেখতে শুরু করে। মানুষ রিপোর্ট করলে “এটা কখনও কখনও আমার সিলেকশন ক্লিয়ার করে” — সেটি পুনরুত্পাদন করতে ঘন্টা যাবে।

রেড ফ্ল্যাগগুলো যা সাধারণত লাইব্রেরি ঝুঁকিতে পড়ছে তা:

• একটি কম্পোনেন্ট শুধুমাত্র একটি নির্দিষ্ট প্রপ ও ইভেন্ট অর্ডারে ব্যবহার করলে কাজ করে।
• একটি composable গ্লোবাল স্টেট পড়ে ও লিখে কিন্তু তা স্পষ্ট করে না।
• একাধিক watcher একই স্টেট আপডেট করে।
• রিফ্যাক্টরগুলো ধারাবাহিকভাবে কনজিউমার স্ক্রিন ভাঙে।
• কনট্রিবিউটররা “ওই ফাইল” ছোঁয়া থেকে বাঁচে কারণ সেটি রিস্কি মনে হয়।

শেষ ফাঁদ হল রিফ্যাক্টরের সময় পাবলিক API ভাঙা। অ্যাডমিন অ্যাপে টেবিল, ফিল্টার, ফর্ম ফিল্ড দ্রুত ছড়িয়ে পড়ে। একটি prop-renaming, emitted event-তে টুইক, বা slot আচরণ বদলানো নিঃশব্দে ডজন কয় স্ক্রিন ভাঙতে পারে।

একটি নিরাপদ পদ্ধতি হল কম্পোনেন্ট API-কে কনট্রাক্ট হিসেবে দেখা: ডিপ্রিকেট করুন মুছবেন না, সাময়িক কম্প্যাটিবিলিটি শিম রাখুন, এবং সাধারণ ব্যবহার মাউন্ট করে এমন সহজ টেস্ট যোগ করুন। যদি আপনি Vue 3 অ্যাডমিন ইন্টারফেস AppMaster-এর মত টুল দিয়ে জেনারেট করেন, তখন কনসিস্টেন্ট কনট্রাক্টগুলো পুনরায় ব্যবহার সহজ করে এবং পরিবর্তনগুলো predict করা সহজ হয়।

সিদ্ধান্ত নেওয়ার আগে দ্রুত চেকলিস্ট

Composition API, Options API, বা মিশ্রণ বেছে নেওয়ার আগে লাইব্রেরির কিছু বাস্তব কম্পোনেন্টে কয়েকটি দ্রুত চেক করুন। লক্ষ্য সহজ: লজিক দ্রুত খুঁজে থাকা, নিরাপদে reuse করা, এবং অ্যাডমিনরা নির্ভর করে এমন অংশগুলো পরীক্ষা করা সহজ করা।

1) কেউ কি লজিক দ্রুত খুঁজে পায়?

একটি সাধারণ অ্যাডমিন-ওয়েটি কম্পোনেন্ট খুলুন (ফিল্টার + টেবিল + পারমিশন + বাল্ক অ্যাকশন)। এখন নিজেকে নতুন কোডবেসে ভেবে দেখুন।

ভাল চিহ্ন হলে একজন কনট্রিবিউটার বলবে “ফিল্টার লজিক কোথায়?” বা “বাটন কবে disabled করে?” দুই মিনিটের মধ্যে। Options API-তে এটি সাধারণত মানে লজিক computed, methods, এবং watchers-এ পরিষ্কারভাবে বিভক্ত। Composition API-তে মানে setup() ছোট নামকৃত ব্লক (বা composables) নিয়ে সাজানো এবং একটি বড় জায়গায় সবকিছু এক জায়গায় না।

2) শেয়ার্ড ইউটিলিটিগুলো ফাংশনের মত আচরণ করে না কি ম্যাজিকের মত?

যেই প্যাটার্নই বেছে নিন না কেন, শেয়ার্ড কোডের ইনপুট ও আউটপুট স্পষ্ট হওয়া উচিত এবং সামান্তর্য সাইড-এফেক্ট কম থাকা উচিত। যদি একটি হেল্পার গ্লোবাল স্টেট অ্যাক্সেস করে, পাস করা অবজেক্ট মিউটেট করে, বা নেটওয়ার্ক কল ট্রিগার করে স্পষ্ট না করে, reuse ঝুঁকিপূর্ণ হয়।

দ্রুত চেক:

• আপনি কি একটি composable বা হেল্পার সিগনেচার পড়ে অনুমান করতে পারবেন এটা কি রিটার্ন করে?
• আপনি কি এটাকে দুইটি কম্পোনেন্টে ব্যবহার করতে পারবেন অতিরিক্ত হিডেন সেটআপ ছাড়া?
• টেস্টে কি আপনি এর স্টেট রিসেট করতে পারবেন হ্যাক ছাড়া?

3) আপনার টেস্টগুলো কি অ্যাডমিন আচরণের ওপর ফোকাস করে?

অ্যাডমিন-স্টাইল অ্যাপগুলো নির্দিষ্টভাবে ব্যর্থ হয়: ফিল্টার ভুল প্রয়োগ করে, পারমিশন অ্যাকশন লিক করে, ফর্ম অননুমোদিতভাবে ভ্যালিডেট করে, এবং টেবিল স্টেট এডিটের পরে ভাঙে। ইমপ্লিমেন্টেশন ডিটেইলস (watchers বনাম refs) টেস্ট না করে আচরণ ভিত্তিক টেস্ট লিখুন: “Role X থাকলে action Y লুকানো”, “save করলে error দেখায় ও ইউজার ইনপুট রেখে দেয়”, “filter পরিবর্তন করলে query ও empty state আপডেট হয়”। এর ফলে রিফ্যাক্টরিং স্টাইল বদলালে টেস্ট স্থিতিশীল থাকে।

4) অ্যাসিঙ্ক স্টেটের জন্য একটি স্টান্ডার্ড আছে কি?

বড় লাইব্রেরি বহু ছোট অ্যাসিঙ্ক ফ্লো তৈরি করে: অপশন লোড, ফিল্ড ভ্যালিডেট, টেবিল রো লোড, ফেইল হলে রিটারাই। যদি প্রতিটি কম্পোনেন্ট আলাদা loading/error কাঠামো বানায়, অনবোর্ডিং ও ডিবাগিং ধীর হয়ে যায়।

একটি পরিষ্কার শেপ (loading, error, retries, cancellation) বেছে নিন। Composition API সাধারণত একটি reusable useAsyncX() composable উৎসাহ দেয়, যেটা Options API-তে data() state ও শেয়ার্ড methods দিয়ে মানকৃত করা যায়। মেইন বিষয় হল ধারাবাহিকতা।

5) কম্পোনেন্ট পাবলিক API কি স্বচ্ছ ও স্থিতিশীল?

কম্পোনেন্টকে একটি প্রোডাক্ট হিসেবে দেখুন। তাদের props, emitted events, এবং slots কনট্রাক্ট। যদি কনট্রাক্ট বারবার বদলে যায়, প্রতিটি অ্যাডমিন স্ক্রিন নাজুক হয়।

ইনটেন্ট ব্যাখ্যা করে এমন মন্তব্য খোঁজ করুন (মেকানিক্স নয়): কোন props মানে কি, কোন ইভেন্ট গ্যারান্টিযুক্ত, এবং কীই অভ্যন্তরীণ ধরা হয়। যদি আপনি AppMaster-এর মত প্ল্যাটফর্ম নিয়ে কাজ করেন, এই চিন্তাভাবনাও প্রযোজ্য: স্থিতিশীল বিল্ডিং ব্লক ভবিষ্যৎ স্ক্রিন দ্রুত শিপ করতে সাহায্য করে।

উদাহরণ সিনারিও ও আপনার টিমের পরবর্তী ধাপ

একটি Users পেজ কল্পনা করুন যা আপনি আবার তৈরি করছেন: একটি ফিল্টার বার (status, role, created date), একটি সিলেক্টেবল রো সহ টেবিল, বাল্ক অ্যাকশন (disable, delete, export), এবং রোল-ভিত্তিক অ্যাক্সেস (শুধু admins বাল্ক delete করতে পারবে, managers role edit করতে পারবে)।

Composition API বনাম Options API-এ UI একই দেখতেই পারে, কিন্তু কোড আলাদাভাবে সংগঠিত হয়।

Options API-তে আপনি প্রায়ই একটা বড় কম্পোনেন্ট পেয়ে যাবেন যার data-তে filters ও selection, computed-এ ডেরাইভড স্টেট, এবং methods-এ fetching, বাল্ক অ্যাকশন, ও পারমিশন চেক থাকবে। reuse সাধারণত mixins বা শেয়ার্ড হেল্পারে প্রদর্শিত হয়। এটা পরিচিত, তবে সম্পর্কিত লজিক ছড়িয়ে পড়তে পারে (fetching methods-এ, query sync watchers-এ, permissions computed-এ)।

Composition API-তে আপনি সাধারণত পেজটিকে কেন্দ্রীভূত composables-এ ভাগ করবেন: একটি query ও filters-এর জন্য, একটি টেবিল সিলেকশন ও বাল্ক অ্যাকশনের জন্য, এবং একটি পারমিশন-এর জন্য। পেজ কম্পোনেন্টটি এসব অংশকে অ্যাসেম্বল করে এবং প্রতিটি কনসার্নের লজিক একসাথে থাকে। ট্রেডঅফ হল সম্ভাব্য "ম্যাজিক ইন setup"-এর ধারণা এড়াতে পরিষ্কার নামকরণ ও ফোল্ডার কনভেনশন দরকার।

রিইউজ সাধারণত অ্যাডমিন লাইব্রেরিতে দেখা যায়: URL-এ সিঙ্ক হওয়া ফিল্টার, সার্ভার-সাইড টেবিল প্যাটার্ন (pagination, sorting, select-all, বাল্ক অ্যাকশন গার্ড), পারমিশন চেক ও UI গেটিং, এবং একসঙ্গে থাকা empty/loading স্টেটগুলো যা পেজে কনসিস্টেন্ট থাকে।

একটি পরবর্তী-ধাপ পরিকল্পনা যা বেশিরভাগ টিমের জন্য কাজ করে:

1. নতুন কোডের জন্য একটি ডিফল্ট স্টাইল বেছে নিন, এবং ব্যতিক্রম কেবল লিখিত কারণে অনুমোদন করুন।
2. কনভেনশন নির্ধারণ করুন: composables কোথায় থাকবে, কীভাবে নামকরণ হবে, কী আমদানি করতে পারবে, এবং কী রিটার্ন করতে হবে।
3. একটি ছোট রেফারেন্স পেজ যোগ করুন (যেমন এই Users পেজ) যা প্যাটার্ন ও স্ট্রাকচারের গোল্ড স্ট্যান্ডার্ড।
4. পুনরায় ব্যবহারযোগ্য অংশগুলো (filters, permissions, bulk actions) প্রথমে টেস্ট লিখে কভার করুন, ভিজ্যুয়াল লেআউট নয়।
5. যদি কিছু অ্যাডমিন স্ক্রিনে গহ্বর কাস্টমাইজেশন চাই না থাকে এবং স্পিড বেশি গুরুত্বপূর্ণ হয়, তাহলে সেই স্ক্রিনগুলো নো-কোড টুল দিয়ে জেনারেট করুন (যেমন AppMaster), আর হাতে লেখা লাইব্রেরি সত্যিই ইউনিক অংশগুলোকে ফোকাস করুক।

আপনি যদি ইতিমধ্যেই AppMaster দিয়ে কাজ করে থাকেন, একই মানসিক মডেল জেনারেটেড ও হ্যান্ড-রাইটেন অংশের মধ্যে বজায় রাখুন: স্থির কম্পোনেন্ট কনট্রাক্ট এবং ছোট, explicit ইউনিটে প্যাকেজ করা শেয়ার্ড লজিক। AppMaster (appmaster.io) অ্যাপ্লিকেশন (ব্যাকএন্ড, ওয়েব, মোবাইল) জেনারেট করার জন্য তৈরি, এবং তা এমনভাবে কাজ করে যাতে আপনি Vue 3 ওয়েব UI-তে যেখানে দরকার সেখানে স্ট্যান্ডার্ডাইজ করতে পারেন।

এই সপ্তাহে যদি আপনি একটাই কাজ করেন, Users পেজটাকে আপনার টেমপ্লেট বানান এবং কোড রিভিউতে সেটি প্রয়োগ করুন। একটি স্পষ্ট উদাহরণ দীর্ঘ স্টাইল গাইডের চেয়ে বেশি করতে পারে।