খালি মান null হবে নাকি ফিল্ড বাদ?

এদের অর্থ আলাদা। `null` মানে ফিল্ড আছে কিন্তু মান নেই; বাদ দেওয়া মানে ফিল্ডই নেই। ভোক্তাকে এদের আলাদা করতে হবে কি না তা দিয়ে ঠিক করুন। PATCH বডিতে করতে হবে: `null` ফিল্ড মুছে, অনুপস্থিতি অক্ষত রাখে। রেসপন্সে `null` রাখুন যাতে আকৃতি স্থিতিশীল থাকে। কনফিগ মার্জে বাদ মানে "ডিফল্ট ব্যবহার", অথচ `null` মানে "স্পষ্টভাবে নিষ্ক্রিয়"।

null নাকি ফিল্ড বাদ

সংক্ষেপে: `null` বলে ফিল্ড আছে কিন্তু মান নেই; বাদ দেওয়া বলে ফিল্ডটাই নেই। PATCH বডি, কনফিগ মার্জ ও ফর্ম প্রিফিল — এখানেই পার্থক্যটা কামড়ায়।

মধ্যবর্তী~3 মিনিট পড়াপ্রকাশ 2026-10-30আপডেট 2026-10-30

মূল কথা: ভোক্তাকে "মুছে ফেলা" ও "অস্পর্শিত" আলাদা করতে হলে null পাঠান — PATCH বডিতে অনুপস্থিতি ফিল্ড অক্ষত রাখে আর স্পষ্ট null তা মুছে — আর প্রতি ফিল্ডে এক প্রথা রাখুন যাতে রেসপন্স ও কনফিগ মার্জ স্থিতিশীল থাকে।

পার্থক্য

复制{ "nickname": null }

উপস্থিত, খালি। ভোক্তা জানে ফিল্ড স্পষ্টভাবে মুছে ফেলা হয়েছে।

复制{ }

অনুপস্থিত। ভোক্তা "কখনো সেট হয়নি" আর "সমর্থিত নয়" আলাদা করতে পারে না।

JavaScript-এ পার্থক্য বাস্তব:

复制'nickname' in obj          // false — absent
obj.nickname === null      // true  — present and null
obj.nickname === undefined // true  — both cases

কোথায় গুরুত্বপূর্ণ

PATCH বডি। {"nickname": null} nickname মুছে। {} কিছুই বদলায় না। হ্যান্ডলার "null" ও "অনুপস্থিত" একই ধরলে ব্যবহারকারী কখনো ফিল্ড মুছতে পারে না — কেবল খালি স্ট্রিং সেট করতে পারে, যা আলাদা জিনিস।

মান নয়, কি-উপস্থিতি দিয়ে বাস্তবায়ন করুন:

复制if (Object.hasOwn(patch, 'nickname')) {
  target.nickname = patch.nickname;   // null allowed
}

কনফিগ মার্জ। বাদ দেওয়া ডিফল্ট উত্তরাধিকার পায়; null স্পষ্টভাবে নিষ্ক্রিয় করে। Helm ও Kubernetes values ঠিক এভাবেই আচরণ করে।

ফর্ম প্রিফিল। null খালি দেখায়, অনুপস্থিত ফিল্ডও খালি দেখায়, কিন্তু জমা ভিন্ন: মান ছিল, এখন মুছে → null পাঠান; কখনো ভরা হয়নি → বাদ দিন। পার্থক্য না থাকলে মুছে ফেলা আর অস্পর্শিত একই দেখায়।

প্রথা

পরিস্থিতি	প্রথা
রেসপন্স বডি	`null` রাখুন; স্থিতিশীল আকৃতি, সরল টাইপ
PATCH রিকোয়েস্ট	`null` মুছে, অনুপস্থিতি রাখে
PUT (পূর্ণ প্রতিস্থাপন)	অনুপস্থিতি মানে মুছে ফেলা — পুরো ডকুমেন্ট প্রতিস্থাপিত
কনফিগ মার্জ	বাদ = ডিফল্ট, `null` = নিষ্ক্রিয়
ডেটাবেস	অজানা বা প্রযোজ্য নয় বোঝাতে `null`; পরিচিত-খালি বোঝাতে `''`

রেসপন্সের আকৃতি স্থিতিশীল রাখুন। তালিকায় কিছু আইটেমে avatar আছে আর কিছুতে নেই হলে প্রতিটি কল সাইটে 'avatar' in item চেক করতে হয়। avatar: null ভোগ করা সহজ।

যা করা উচিত নয়

null-এর জন্য "" ব্যবহার নয়। খালি nickname আর অনির্ধারিত nickname বেশিরভাগ ডোমেইনে আলাদা অবস্থা।

Sentinel হিসেবে 0 বা -1 নয়। শূন্য বৈধ সংখ্যা, আর sentinel আপনার প্রতিটি গড় গণনা নষ্ট করে।

এন্ডপয়েন্ট অনুযায়ী প্রথা মেশানো নয়। দুই প্রথা মানে প্রতিটি ক্লায়েন্টে দুই কোড পথ।

সাধারণ প্রশ্ন

null ও বাদ দেওয়া ফিল্ডের মধ্যে কী ঠিক করে?

ভোক্তাকে "স্পষ্টভাবে মুছে ফেলা" ও "কখনো সেট হয়নি" আলাদা করতে হবে কি না জিজ্ঞাসা করুন। PATCH বডিতে করতে হবে, তাই null মুছে আর অনুপস্থিতি রাখে; রেসপন্সে null রাখলে আকৃতি স্থিতিশীল ও ক্লায়েন্ট টাইপ সরল হয়।

PATCH এন্ডপয়েন্ট মুছে ফেলা আর অক্ষত রাখা কীভাবে আলাদা করে?

মান নয়, কি-উপস্থিতি দেখুন: Object.hasOwn(patch, 'nickname') বলে ফিল্ড পাঠানো হয়েছে, কেবল তারপর অ্যাসাইন করুন, null-সহ। হ্যান্ডলার null ও অনুপস্থিতিকে একই ধরলে ব্যবহারকারী কখনো ফিল্ড মুছতে পারে না, কেবল খালি স্ট্রিংয়ে ফিরতে পারে।

রেসপন্স বডি null রাখা উচিত কেন?

স্থিতিশীল আকৃতি মানে ক্লায়েন্টকে প্রতিটি ঐচ্ছিক কি-এর জন্য 'avatar' in item চেক করতে হয় না। তালিকার কিছু আইটেমে avatar থাকলে আর কিছুতে বাদ দেওয়া হলে সেই চেক প্রতিটি কল সাইটে পুনরাবৃত্তি হয় আর ভুল করা সহজ।