অ্যাডমিন UI-তে বড় ড্রপডাউন: কেন এটা আপনাকে ধীর করে

বড় ড্রপডাউনের পেছনের বাস্তব সমস্যা

আপনি একটি ফিল্ডে ক্লিক করেন, ড্রপডাউন খুলে যায়, এবং সবকিছু ধীর হয়ে যায়। পেজ একটু স্টাটার করে, স্ক্রল আটকে মনে হয়, এবং আপনি আপনার জায়গা হারান। যদিও এটা মাত্র এক সেকেন্ডই নেবে, সেটা ফর্ম পূরণের রিদম ভেঙে দেয়।

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

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

বাস্তব সমস্যা কেবল দ্রুততা নয় — এটি সঠিকতা।

লম্বা তালিকা স্ক্রল করলে মানুষ ভুল "জন স্মিথ", ভুল "স্প্রিংফিল্ড" বা ভুল প্রোডাক্ট ভ্যারিয়েন্ট বেছে নেয়, তারপর খারাপ ডেটা সেভ হয়। খরচ পরবর্তীতে সাপোর্ট কাজ, পুনরায় এডিট এবং অকাঙ্খিত রিপোর্ট হিসেবে দেখা দেয়।

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

ধীর হওয়ার উৎস (সহজ ভাষায়)

একটি বিশাল ড্রপডাউন সাধারণ মনে হলেও ব্রাউজার এটা বাস্তব কাজ হিসেবে গ্রহণ করে। আপনি হাজারো আইটেম লোড করলে পেজকে হাজার হাজার option এলেমেন্ট তৈরি করতে বলা হচ্ছে, সেগুলো মেপে স্ক্রিনে পেইন্ট করতে হচ্ছে। ওই DOM এবং রেন্ডারিং খরচ দ্রুত যোগ হয়, বিশেষ করে ফর্মে এমন কয়েকটি ফিল্ড থাকলে।

ধীরতা তখনও শুরু হতে পারে যখন কিছুই দৃশ্যমান হয়নি। অনেক অ্যাডমিন UI রেফারেন্স লিস্ট (গ্রাহক, প্রোডাক্ট, লোকেশন) প্রলোড করে যাতে ড্রপডাউন পরে দ্রুত খোলে। এর মানে বড় API রেসপন্স, নেটওয়ার্কে বেশি অপেক্ষা, এবং JSON পার্সিংয়ে বেশি সময়। ভাল কানেকশনে ও এ মাসে, বড় পেলোড ফর্মটি ইন্টারঅ্যাকটিভ হওয়ার মুহূর্ত দেরি করে।

তারপর আছে মেমরি। বড় তালিকা ব্রাউজারে রাখলে RAM লাগে। কম ক্ষমতার ল্যাপটপ, পুরোনো ব্রাউজার বা ব্যস্ত ট্যাবে এটা স্টাটার, টাইপিং ধীর বা এমনকি ড্রপডাউন খোলার সময় সাময়িক ফ্রিজ তৈরি করতে পারে।

ব্যবহারকারীরা প্রযুক্তিগত কারণ নিয়ে চিন্তা করে না — তারা বিরতি লক্ষ্য করে। সাধারণ ছোট "মাইক্রো-ডিলে" গুলোই ফ্লো ভাঙ্গে:

• পেজ লোড হয়, কিন্তু প্রথম ক্লিক কিছুক্ষণের জন্য কিছুই করে না।
• ড্রপডাউন খোলায় ল্যাগ হয় বা স্ক্রল জাম্পি লাগে।
• অন্য ফিল্ডে টাইপিং একটু বিলম্বিত হয়।
• সেভ করা ধীর লাগে কারণ UI ইতিমধ্যেই লোডে আছে।

৩০০ থেকে ৬০০ ms এর হিকআপ বেশি মনে না হলেও, দিনের পর দিন ডেটা এন্ট্রিতে বার বার ঘটলে তা বাস্তবে বিরক্তিকর হয়ে দাঁড়ায়।

UX সমস্যা: এটা কেবল পারফরম্যান্স নয়

বড় ড্রপডাউন কেবল ধীর মনে হয় না। এগুলো সরল পছন্দকে একটি ছোট ধাঁধায় পরিণত করে, এবং ব্যবহারকারীরা প্রতিবারই এর মূল্য চৌড়া মাশুল দেয়।

মানুষ ২,০০০ আইটেম কার্যকরভাবে স্ক্যান করতে পারে না। তালিকা যদি ততক্ষণে লোডও হয়, চোখকে "হান্ট মোডে" ঠেলে দেয়: স্ক্রল, বেশি চলে যায়, ফিরিয়ে স্ক্রল, সন্দেহ করা। তালিকা বড় হলে ব্যবহারকারীরা সঠিকটি বেছে নেওয়ার স্থলে সময় খরচ করে।

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

নেটিভ সিলেক্টের "সার্চ" আরেকটি ফাঁদ। কিছু প্ল্যাটফর্মে টাইপ করলে ওই অক্ষর দিয়ে শুরু হওয়া পরবর্তী আইটেমে কুড়ায়; অন্যগুলিতে ভিন্ন আচরণ করে বা ডিসকভারি অসম্ভব। ব্যবহারকারীরা আপনার অ্যাপকেই দোষ দেয়, যদিও কন্ট্রোল সাধারণ ড্রপডাউন মতো আচরণ করছে।

দীর্ঘ তালিকা ডেটা गुणवत्ता প্রবলেমগুলোও লুকিয়ে রাখে। ডুপ্লিকেট, অস্পষ্ট নাম, পুরানো আর্কাইভ হওয়া রেকর্ড, এবং শুধুমাত্র সাফিক্সে আলাদা অপশনগুলো শব্দের ভিতরে অদৃশ্য হয়ে যায়।

কোনো "একটি নির্বাচন" ফিল্ডের দ্রুত বাস্তবতা পরীক্ষা:

• কি একজন নতুন সহকর্মী প্রথমবারেই সঠিকভাবে বেছে নিতে পারবে?
• near-duplicate নাম আছে কি যে ভুল করতে উত্সাহিত করে?
• Mac, Windows, এবং মোবাইলে কন্ট্রোল একইভাবে আচরণ করে কি?
• যদি নির্বাচন ভুল হয়, কি কেউ তা সঙ্গে সঙ্গেই লক্ষ্য করবে?

কখন ড্রপডাউনই ঠিক সিদ্ধান্ত

প্রতিটি সিলেক্ট ফিল্ডে সার্চ প্রয়োজন নেই। বড় ড্রপডাউন কষ্টদায়ক হয় যখন তালিকা লম্বা, ঘনঘন বদলে বা কনটেক্সট-নির্ভর। কিন্তু ছোট, স্থিতিশীল অপশন সেটই ড্রপডাউনের জন্য আদর্শ।

যখন মানুষ দ্রুত স্ক্যান করে এবং চিন্তা না করে সঠিক মান চিনতে পারে, তখন ড্রপডাউন ভাল অপশন। যেমন অর্ডার স্ট্যাটাস, অগ্রাধিকার, ইউজার রোল বা দেশ — যদি তালিকাটি সময়ের সঙ্গে প্রায় একই থাকে এবং সাধারণত এক স্ক্রিনে ফিট করে, সহজ কন্ট্রোলই সেরা।

সাধারণদিশা: যদি তালিকা সাধারণত ৫০–১০০ আইটেমের কম থাকে এবং মানুষ পড়ে বেছে নেয়, আপনি গতি ও স্পষ্টতা দুটোই পাবেন।

ব্যবহারকারীরা একই প্রথম অক্ষর বারবার টাইপ করতে শুরু করলে সতর্ক হন — এটা ইঙ্গিত যে তালিকা মনে রাখা যায় না এবং স্ক্যানিং সার্চের চেয়ে ধীর হয়ে পড়েছে।

কঠোর সিদ্ধান্ত হচ্ছে যে কোনো তালিকা যা ঘনঘন বদলে বা লগ-ইন করা ব্যক্তির উপর নির্ভর করে। "Assigned to" প্রায়ই টিম, রিজিয়ন এবং পারমিশনের ওপর নির্ভর করে। সব ইউজার লোড করা ড্রপডাউন পুরনো, ভারী ও বিভ্রান্তিকর হবে।

AppMaster-এর মতো টুলে কিছু নিয়ম: ছোট রেফারেন্স ডেটার জন্য ড্রপডাউন রাখুন (স্ট্যাটাসের মতো), এবং ব্যবসা বাড়লে গ্রাহক, প্রোডাক্ট, স্টাফের জন্য সার্চ-ভিত্তিক পিকারে স্যুইচ করুন।

টাইপঅহেড সার্চ: সবচেয়ে সরল বিকল্প

টাইপঅহেড (অথবা অটোকমপ্লিট) হচ্ছে একটি টেক্সট ফিল্ড যা টাইপ করার সঙ্গে সঙ্গে সার্চ করে এবং সামান্য মিল দেখায়। মানুষকে বিশাল তালিকা স্ক্রল করতে বলার বদলে কীবোর্ড ব্যবহার করতে দিন এবং রিয়েল-টাইমে আপডেট হওয়া সীমিত ফলাফল থেকে বেছে নিতে দিন।

এটি সাধারণত প্রথমেই সবচেয়ে ভালো সমাধান কারণ এটি রেন্ডার করা কমায়, ডাউনলোড কমায় এবং সঠিক আইটেম খুঁজে পেতে ব্যর্থ প্রচেষ্টা হ্রাস করে।

ভালো টাইপঅহেড কয়েকটি মৌলিক নিয়ম মেনে চলে। এটি সার্চ চালাতে কমপক্ষে 2–3 অক্ষরের জন্য অপেক্ষা করে যাতে "a" বা "e"-তে UI থ্র্যাশ না করে। এটি দ্রুত ফলাফল দেয় এবং তালিকাটি ছোট রাখে (সাধারণত শীর্ষ 10–20 মিল)। মিলের অংশকে হাইলাইট করে যাতে স্ক্যানিং দ্রুত হয়। খালি স্টেটে পরিষ্কার "কোন ফলাফল নেই" বার্তা এবং পরবর্তী ধাপ দেখানো থাকে।

কীবোর্ড আচরণ মানুষ যতটা মনে করে তার চেয়ে বেশি গুরুত্বপূর্ণ: Up/Down অপশনের মধ্যে নেভিগেট করা উচিত, Enter সিলেক্ট করা উচিত, এবং Esc বন্ধ করা উচিত। যদি এই বেসিক মিসিং থাকে, টাইপঅহেড ড্রপডাউনের থেকেও খারাপ মনে হতে পারে।

ছোট ডিটেইলগুলোই এটি স্থির রাখে। সূক্ষ্ম লোডিং স্টেট ডাবল-টাইপিং ও বিভ্রান্তি কমায়। যদি কেউ "jo" টাইপ করে এবং বিরাম দেয়, ফলাফল দ্রুত আসা উচিত। যদি তারা "john sm" টাইপ করে, তালিকাটি সংকীর্ণ হওয়া উচিত যাতে হাইলাইটেড সিলেকশন হারায় না।

উদাহরণ: একটি অ্যাডমিন প্যানেলে যেখানে আপনি একটি গ্রাহক বেছে নেন, "mi" টাইপ করা মানে হতে পারে "Miller Hardware", "Mina Patel" এবং "Midtown Bikes", যেখানে "mi" অংশটি হাইলাইট থাকবে। AppMaster-এ এই প্যাটার্ন স্বাভাবিক কারণ আপনার UI একটি এন্ডপয়েন্টকে কল করে গ্রাহক সার্চ করতে পারে এবং প্রয়োজনীয় কয়েকটি মিলই ফেরত দেয়, পুরো টেবিল নয়।

যদি সত্যিই কোন মিল না থাকে, সরাসরি এবং সহায়ক হোন: "No customers found for 'johns'. Try a shorter name or search by email." — (UI তে ব্যবহারকারীর জন্য পরামর্শ দেখান)।

টাইপঅহেড বাস্তবায়ন: ধাপে ধাপে

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

একটি বাস্তবসম্মত, দ্রুত সেটআপ

প্রথমে সেই এক বা দুইটি ফিল্ড বেছে নিন যা মানুষ আসলে মনে রাখে। গ্রাহকদের জন্য সাধারণত নাম বা ইমেল। প্রোডাক্টের জন্য SKU বা অভ্যন্তরীণ কোড। এই পছন্দ স্টাইলিংয়ের থেকে বেশি গুরুত্বপূর্ণ কারণ এটি নির্ধারণ করে ব্যবহারকারী প্রথম কয়েক হলেই ফলাফল পাবে কি না।

তারপর ফ্লোটি এন্ড-টু-এন্ড বাস্তবায়ন করুন:

• সার্চ কি নির্বাচন করুন (উদাহরণ: গ্রাহকের নাম এবং ইমেল) এবং একটি সর্বনিম্ন অক্ষর সংখ্যা সেট করুন (সাধারণত 2–3)।
• একটি API এন্ডপয়েন্ট তৈরি করুন যা কুয়েরি টেক্সট এবং পেজিং গ্রহণ করে (উদাহরণ q এবং limit, প্লাস offset বা একটি কারসর)।
• শুধুমাত্র ছোট সেট ফেরত দিন (সাধারণত শীর্ষ 20), সেরা মিল অনুসারে সাজিয়ে, এবং ID প্লাস ডিসপ্লে ফিল্ড পাঠান।
• UI-তে লোডিং স্টেট দেখান, খালি ফলাফল হ্যান্ডেল করুন, এবং কীবোর্ড নেভিগেশন সাপোর্ট করুন।
• নির্বাচিত রেকর্ড ID হিসেবে সেভ করুন, ডিসপ্লে টেক্সট হিসেবে নয়। লেবেল কেবল প্রদর্শনের জন্য ধরুন।

ছোট উদাহরণ: যদি একজন অ্যাডমিন "maria@" টাইপ করে একটি Customer ফিল্ডে, UI এন্ডপয়েন্টকে q=maria@ পাঠায় এবং 20 মিল ফিরে পায়। ব্যবহারকারী সঠিকটি বেছে নেয়, এবং ফর্মে customer_id=12345 সেভ হয়। ভবিষ্যতে যদি ওই গ্রাহকের নাম বা ইমেল বদলে যায়, আপনার সেভ করা ডেটা ঠিক থাকবে।

AppMaster-এ তৈরি করলে একই ধারণা প্রযোজ্য: সার্চের জন্য ব্যাকএন্ড এন্ডপয়েন্ট (পেজিং সহ) ব্যবহার করুন, UI ফিল্ডকে সেটার সাথে কানেক্ট করুন, এবং নির্বাচিত মান মডেল ID-তে বাইন্ড করুন।

দুটি বিষয়ে খেয়াল রাখুন যা রেসপনসিভ রাখে: রিকুয়েস্ট ডিবাউন্স করুন (প্রতিটি কীস্ট্রোকেই সার্ভারে কল না করা) এবং চলতি সেশনে সাম্প্রতিক কুয়েরিগুলো ক্যাশ করুন।

সার্ভার-সাইড ফিল্টারিং প্যাটার্ন যা দ্রুত থাকে

তালিকা কয়েকশোর বেশি হলে ব্রাউজারে ফিল্টার করা আর বন্ধুত্বপূর্ণ নয়। পেজ অপ্রয়োজনীয় ডেটা ডাউনলোড করে, তারপর একটু অংশ দেখানোর জন্য অতিরিক্ত কাজ করে।

সার্ভার-সাইড ফিল্টারিং ফ্লো উল্টে দেয়: একটি ছোট কুয়েরি পাঠান (যেমন "name starts with ali"), ফেরত পান কেবল প্রথম পেজ মিলের, এবং ফর্ম যে কোনো বড় টেবিলের সাইজের ওপর নির্ভর করেও রেসপনসিভ থাকে।

উত্তর সময় স্থির রাখার কিছু প্যাটার্ন

কয়েকটি সহজ নিয়ম বড় পার্থক্য তৈরি করে:

• সীমিত পেজ সাইজ ফেরত দিন (উদাহরণ 20–50 আইটেম) এবং একটি "next" টোকেন বা পেজ নম্বর সহ দিন।
• পরিবর্তনশীল ডেটার জন্য কারসর-ভিত্তিক পেজিং প্রাধান্য দিন যাতে রেকর্ড যোগ হলে গ্যাপ না হয়।
• UI-কে যে শুধু দরকারি ফিল্ডগুলোই (id এবং লেবেল) চাই তা সার্ভার থেকে নিন, পুরো রেকর্ড নয়।
• স্থির সাজানো ব্যবহার করুন (উদাহরণ: নাম দ্বারা, তারপর id) যাতে ফলাফল কুদাফ করে না।
• কুয়েরিতেই বর্তমান ব্যবহারকারীর পারমিশন প্রয়োগ করুন, পরে নয়।

ক্যাশিং: সাহায্য করে, কিন্তু ভুল হওয়াও সহজ

ক্যাশিং জনপ্রিয় সার্চ দ্রুত করতে পারে, কিন্তু সেটি তখনই নিরাপদ যখন ফলাফলটি পুনরায় ব্যবহার যোগ্য। "Top countries" বা "common product categories" ভালো কেস। গ্রাহক তালিকা সাধারণত নয়, কারণ ফলাফল পারমিশন, অ্যাকাউন্ট স্ট্যাটাস বা সাম্প্রতিক পরিবর্তনের ওপর নির্ভর করতে পারে।

যদি আপনি ক্যাশ করেন, ছোটসময়ের জন্য রাখুন এবং কেশি-কিরি কী-তে ব্যবহারকারী রোল বা টেন্যান্ট অন্তর্ভুক্ত করুন। নাহলে একজন অন্যের ডেটা দেখতে পারে।

AppMaster-এ এটি সাধারণত মানে একটি এন্ডপয়েন্ট বানানো যা সার্চ স্ট্রিং এবং কারসর গ্রহণ করে, তারপর রিটার্ন করার আগে ব্যাকএন্ড লজিকে এক্সেস রুল প্রয়োগ করে।

রেফারেন্স-ডেটা প্যাটার্ন যা ফর্ম দ্রুত রাখে

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

রেফারেন্স টেবিলগুলোকে নির্ঘাত এবং সঙ্গত রাখুন। প্রতিটি রো-কে একটি স্পষ্ট, ইউনিক কী দিন (সাধারণত একটি নম্বরভিত্তিক ID) এবং এমন একটি নাম দিন যা ব্যবহারকারী চিনছে। ডিলিট করার বদলে একটি active/inactive ফ্ল্যাগ রাখুন, যাতে পুরানো রেকর্ডগুলো এখনও রেজলভ হয় কিন্তু নতুন সিলেকশনে না আসে। এটি টাইপঅহেড ও সার্ভার-সাইড ফিল্টারিংকে নিরাপদ করে, কারণ আপনি ডিফল্টভাবে active=true ফিল্টার প্রয়োগ করতে পারেন।

আগেই নির্ধারণ করুন যে কি লেবেল স্ন্যাপশট করতে চাইবেন কি না। একটি ইনভয়েস লাইনে customer_id থাকতে পারে, কিন্তু audit ও বিরোধের জন্য customer_name_at_purchase রাখতে চাইতে পারেন। দৈনন্দিন অ্যাডমিন রেকর্ডে প্রায়শই ভালো হয় সবসময় জয়েন করে বর্তমান নাম দেখানো, যাতে টাইপো ঠিক করলে সবার কাছে আপডেট দেখা যায়। সহজ নিয়ম: যেখানে অতীত অটোমেটিকভাবে পড়তে হবে সেখানে স্ন্যাপশট রাখুন।

দ্রুততার জন্য ছোট শটকাটগুলো সার্চ কমাতে পারে বিনা পুরো ডেটাসেট লোড করে। প্রতিটি ব্যবহারকারীর "recently used" আইটেমগুলো উপরে দেখানো প্রায়ই কোনো UI টিউনিংয়ের চেয়ে বেশি কার্যকর। ফেভারিটস সাহায্য করে যখন মানুষ একই কয়েকটি জিনিস প্রতিদিন পিকার। নিরাপদ ডিফল্ট (যেমন শেষ ব্যবহৃত মান) পুরো ইন্টারঅ্যাকশন বাদ দিতে পারে। এবং ডিফল্টভাবে নিষ্ক্রিয় আইটেমগুলো লুকিয়ে রাখলে তালিকা পরিষ্কার থাকে।

উদাহরণ: একটি অর্ডারে গুদাম বেছে নিলে warehouse_id সেভ করুন। গুদাম নাম দেখান, কিন্তু অডিট ট্রেইলের জন্য ছাড়া এমবেড করবেন না। AppMaster-এ এটি পরিষ্কারভাবে মানানসই: Data Designer-এ রেফারেন্স মডেল করুন, এবং ব্যবসায়িক লজিকে “recent selections” রেকর্ড করুন যাতে হাজারো অপশন UI-তে লোড না করতে হয়।

সাধারণ ফর্ম সিনারিও এবং উন্নত UI কন্ট্রোল

বড় ড্রপডাউন সাধারণত আসে কারণ একটি ফর্ম ফিল্ড "সরল" মনে হয়: একটি তালিকা থেকে একটি মান পছন্দ করুন। কিন্তু বাস্তব অ্যাডমিন ফিল্ডগুলো দ্রুত ও সহজ রাখার জন্য ভিন্ন কন্ট্রোল প্রয়োজন।

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

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

আরেকটি প্রয়োজনীয়তা হলো "ফিল্ড থেকে নতুন তৈরি" যখন অপশন নেই। ফিল্ডের পাশে বা পিকারে একটি "Add new…" অ্যাকশন রাখুন। নতুন রেকর্ড তৈরি করুন, তারপর এটিকে অটো-সিলেক্ট করুন। সার্ভারে ভ্যালিডেশন করুন (প্রয়োজনীয় ফিল্ড, অনন্যতা যেখানে জরুরি) এবং কনফ্লিক্ট স্পষ্টভাবে হ্যান্ডেল করুন।

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

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

AppMaster-এ ফর্ম বানালে, এই প্যাটার্নগুলো পরিষ্কার ডেটা মডেল (রেফারেন্স টেবিল) এবং সার্ভার-সাইড সার্চ এন্ডপয়েন্টগুলোর সাথে মানানসই হয়, তাই UI ডেটা বাড়ার সাথে সাথেই রেসপনসিভ থাকে।

সাধারণ ভুল যা অবস্থা খারাপ করে

অধিকাংশ ধীর ফর্ম এক বিশাল টেবিলের কারণে ধীর হয় না। UI প্রতিবারই ব্যয়বহুল পছন্দটি বারবার করে।

একটি ক্লাসিক ভুল হল পুরো তালিকাটি "স্রেফ একবার" পেজ লোডে লোড করা। 2,000 আইটেমে এটা ঠিক লাগে। এক বছর পরে সেটা 200,000 হলে প্রতিটি ফর্ম বড় অপেক্ষা, অতিরিক্ত মেমরি ব্যয় এবং ভারি পেলোড নিয়ে খুলবে।

তবে সার্চ দ্রুত হলেও ব্যর্থ হতে পারে। যদি ফিল্ড কেবল ডিসপ্লে নাম দ্বারা সার্চ করে, ব্যবহারকারীরা আটকে যাবে। বাস্তব মানুষ তাদের কাছে থাকা অনুসারে সার্চ করে: গ্রাহকের ইমেল, অভ্যন্তরীণ কোড, ফোন নম্বর বা অ্যাকাউন্টের শেষ 4 ডিজিট।

কয়েকটি বিষয় একটি গ্রহণযোগ্য কন্ট্রোলকে কষ্টকর করে তোলে:

• ডিবাউন্স না থাকা, তাই প্রত্যেক কীস্ট্রোকেই অনুরোধ যায়।
• বড় পেলোড (পূর্ণ রেকর্ড) পাঠানো, ছোট মিলের তালিকা নয়।
• নিষ্ক্রিয় বা ডিলিট করা আইটেম গুলোর হ্যান্ডেল নেই, তাই সেভ করা ফর্ম পরে ফাঁকা দেখায়।
• ফর্ম লেবেল টেক্সট সেভ করে ID না রাখা, ডুপ্লিকেট ও বিশৃঙ্খলা তৈরি করে।
• ফলাফল পর্যাপ্ত প্রসঙ্গ দেখায় না (উদাহরণ: দুইজন "John Smith" কিন্তু কোনো পার্থক্য নেই)।

এক বাস্তব উদাহরণ: একটি এজেন্ট গ্রাহক সিলেক্ট করে। গ্রাহক "Acme" দুইবার আছে, একটি নিষ্ক্রিয়, এবং ফর্ম লেবেল সেভ করেছে। এখন ইনভয়েস ভুল রেকর্ড নির্দেশ করে এবং কেউ নির্ভরযোগ্যভাবে সেটা ঠিক করতে পারে না।

AppMaster-এ নিরাপদ ডিফল্ট হচ্ছে রেফারেন্সগুলো আপনার ডেটা মডেলে ID হিসেবে রাখা এবং লেবেল কেবল UI-এ দেখানো, যখন সার্চ এন্ডপয়েন্ট ছোট, ফিল্টার করা মিল ফেরত দেয়।

শিপ করার আগে দ্রুত চেকলিস্ট

শিপ করার আগে প্রতিটি "তালিকা থেকে বেছে নেওয়া" ফিল্ডকে পারফরম্যান্স ও UX ঝুঁকি হিসেবে বিবেচনা করুন। এই ফিল্ডগুলো টেস্ট ডেটায় ঠিক মনে হয়, কিন্তু প্রকৃত রেকর্ড এলে ভাঙে।

• যদি তালিকা প্রায় 100 আইটেম অতিক্রম করতে পারে, টাইপঅহেড সার্চ বা অন্য সার্চেবল পিকার ব্যবহার করুন।
• সার্চ রেসপন্স ছোট রাখুন — প্রতি কুয়েরিতে প্রায় 20–50 ফলাফল লক্ষ্য করুন, এবং ব্যবহারকারীকে টাইপ করতে বলার জন্য স্পষ্ট ইঙ্গিত দিন।
• স্থির মান সেভ করুন, লেবেল নয়। রেকর্ড ID সেভ করুন এবং সার্ভারে ভ্যালিডেট করুন, পারমিশন চেক সহ, ফর্ম গ্রহণের আগে।
• স্টেটগুলো সচেতনভাবে হ্যান্ডেল করুন: সার্চের সময় লোডিং ইন্ডিকেটর, কিছু না মিললে সহায়ক খালি স্টেট, এবং অনুরোধ ব্যর্থ হলে স্পষ্ট এরর।
• মাউস ছাড়াই দ্রুত করুন। কীবোর্ড নেভিগেশন সাপোর্ট করুন এবং ব্যবহারকারীকে নাম, ইমেল বা কোড পেস্ট করতে দিন।

AppMaster-এর মতো নো-কোড টুলে এটি সাধারণত একটি ছোট পরিবর্তন: একটি ইনপুট UI, একটি সার্চ এন্ডপয়েন্ট, এবং আপনার ব্যবসায়িক লজিকে সার্ভার-সাইড ভ্যালিডেশন। দিনের কাজে ভিন্নতা বিশাল, বিশেষ করে হাই-ট্রাফিক ফর্মে।

বাস্তবসম্মত উদাহরণ: অ্যাডমিন প্যানেলে গ্রাহক নির্বাচন

একটি সাপোর্ট টিম আছে যারা একটি অ্যাডমিন UI-তে কাজ করে যেখানে তারা প্রতিটি আসা টিকিটকে সঠিক গ্রাহকের কাছে অ্যাসাইন করে। সাধারণ মনে হলেও গ্রাহক তালিকা 8,000 রেকর্ডে বাড়লে সমস্যা দেখা দেয়।

"আগে" ভার্সনে একটি বিশাল ড্রপডাউন থাকে। খুলতে সময় লাগে, স্ক্রল ধীর, এবং ব্রাউজার হাজার হাজার অপশন মেমরিতে রাখতে হয়। আরো খারাপ, মানুষ ভুল "Acme" বেছে নেয় কারণ ডুপ্লিকেট, পুরোনো নাম, এবং ক্ষুদ্র পার্থক্য যেমন "ACME Inc" বনাম "Acme, Inc" আছে। ফলাফল হচ্ছে প্রতিনিয়ত ছোট সময় ক্ষতি এবং পরে বিশৃঙ্খল রিপোর্টিং।

"পরে" ভার্সনে ড্রপডাউন বদলে টাইপঅহেড ফিল্ড রাখা হয়েছে। এজেন্ট তিন অক্ষর টাইপ করে সেরা মিলগুলো দ্রুত দেখে নিয়ে সিলেক্ট করে এগিয়ে যায়। ফিল্ড অতিরিক্ত প্রসঙ্গ দেখাতে পারে (ইমেল ডোমেইন, অ্যাকাউন্ট ID, শহর) যাতে সঠিক গ্রাহক স্পষ্ট হয়।

দ্রুত রাখার জন্য সার্চ সার্ভারে ঘটে, ব্রাউজারে নয়। UI কেবল প্রথম 10–20 মিল অনুরোধ করে, প্রাসঙ্গিকতার ভিত্তিতে সাজানো (সাধারণত এক্স্যাক্ট প্রিফিক্স মিল ও সাম্প্রতিক ব্যবহারের মিশ্রণ) এবং স্টেটাস দ্বারা ফিল্টার করা (উদাহরণ: শুধুমাত্র active গ্রাহক)। এই প্যাটার্নই দীর্ঘ তালিকাকে দৈনন্দিন বিরক্তিতে পরিণত হওয়া থেকে রক্ষা করে।

একটি ছোট ডেটা হাইজিন ধাপ নতুন ফ্লোকে অনেক নিরাপদ করে:

• একটি নামকরণ নিয়ম সেট করুন (উদাহরণ: লিগ্যাল নাম প্লাস সিটি বা ডোমেইন)।
• মূল ফিল্ডগুলোতে ডুপ্লিকেট প্রতিরোধ করুন (ইমেল ডোমেইন, ট্যাক্স ID, বা এক্সটার্নাল ID)।
• একটি "display name" ফিল্ড পণ্যজুড়ে ধারাবাহিক রাখুন।
• মিশ্রিত রেকর্ডগুলোকে inactive চিহ্নিত করুন, কিন্তু ইতিহাস রাখুন।

AppMaster-এ সাধারণত এর মানে হচ্ছে একটি সার্চেবল রেফারেন্স ফিল্ড যা ব্যবহারকারী টাইপ করার সঙ্গে সঙ্গে মিল ফেরত দেয়, পরিবর্তে প্রতি ফর্মে সব গ্রাহক লোড করা।

পরবর্তী পদক্ষেপ: একটি ফিল্ড আপগ্রেড করুন এবং প্যাটার্ন স্ট্যান্ডার্ডাইজ করুন

একটি এমন ড্রপডাউন বেছে নিন যা সবাই অভিযোগ করে। ভালো প্রার্থী হচ্ছে এমন একটি ফিল্ড যা বহু স্ক্রিনে দেখা যায় (Customer, Product, Assignee) এবং কয়েকশোর বেশি অপশন বেড়ে গেছে। শুধু ঐ একটি ফিল্ড বদলালে দ্রুত প্রমাণ মেলে, সমস্ত ফর্ম রিরাইট না করেই।

প্রথমে সিদ্ধান্ত নিন এই ফিল্ডটি বাস্তবে কি ইঙ্গিত করে: একটি রেফারেন্স টেবিল (গ্রাহক, ইউজার, SKU) একটি স্থায়ী ID সহ, এবং ছোট ডিসপ্লে ফিল্ডগুলো (নাম, ইমেল, কোড)। এরপর একটি সার্চ এন্ডপয়েন্ট ডিফাইন করুন যা UI-কে দ্রুত, ছোট পেজে কেবল প্রয়োজনীয় ফলাফল দেয়।

রোলআউট প্ল্যান যা বাস্তবে কাজ করে:

• ঐ ড্রপডাউন টাইপঅহেড সার্চ দিয়ে বদলান।
• পার্শ্ববর্তী সার্ভার-সাইড সার্চ তৈরি করুন যা পার্শিয়াল টেক্সট ও পেজিং সাপোর্ট করে।
• ID প্লাস লেবেল (এবং একটি সেকেন্ডারি_HINT যেমন ইমেল) ফেরত দিন।
• নির্বাচিত মান ID হিসেবে রাখুন, কপি করা টেক্সট নয়।
• একই প্যাটার্নকে যেখানে ইন্টিটি পিক করা হয় সব জায়গায় পুনরায় ব্যবহার করুন।

পরিবর্তন পরিমাপ করুন কিছু সহজ সংখ্যার সাহায্যে। ফিল্ড খোলার সময় ট্র্যাক করুন (এইটা তাৎক্ষণিক লাগা উচিত), সিলেক্ট করতে সময় (কমে যাওয়া উচিত), এবং এরর রেট (ভুল পিক, পুনঃসম্পাদনা, বা ব্যবহারকারী ছেড়ে দেওয়া) ট্র্যাক করুন। এমনকি 5–10 বাস্তব ব্যবহারকারী নিয়ে হালকা আগে/পরে পরীক্ষাই দেখাবে যে আপনি সমস্যার সমাধান করলেন কি না।

AppMaster-এ অ্যাডমিন টুল বানালে, আপনি Data Designer-এ রেফারেন্স মডেল করতে এবং Business Process Editor-এ সার্ভার-সাইড সার্চ লজিক যোগ করতে পারেন, যাতে UI কেবল সবকিছু লোড না করে ছোট আউটপুট অনুরোধ করে। appmaster.io-তে নির্মিত অভ্যন্তরীণ অ্যাপগুলোতে দলগুলো প্রায়ই এটি একটি স্ট্যান্ডার্ড প্যাটার্ন হিসেবে গ্রহণ করে, কারণ এটি বড় ডেটাসেট বাড়ার সঙ্গে পরিষ্কারভাবে স্কেল করে।

শেষে, আপনার দলটি পুনরায় ব্যবহার করার জন্য একটি স্ট্যান্ডার্ড লিখে রাখুন: সার্চ চালুর আগে সর্বনিম্ন অক্ষর, ডিফল্ট পেজ সাইজ, লেবেল কীভাবে ফরম্যাট হবে, এবং কোনো ফলাফল না গেলে কি হবে। ধারাবাহিকতা প্রতিটি নতুন ফর্মকে দ্রুত রাখে।