بیاید با یک مثال شروع کنیم. فرض کنیم که قراره یک API برای ساخت کاربر جدید بسازیم. هر کاربری حتما یک فیلد منحصر به فرد ( شماره موبایل، نام کاربری یا ایمیل) داره که باهاش وارد نرم افزار میشه و دو تا کاربر با مقدار یکسان از اون فیلد نباید وجود داشته باشه (یونیک باشه). یکی از راه های جلوگیری از ورود دوباره فیلد منحصر به فرد، اینه که مقدارش رو در دیتابیس بررسی کنیم و اگر وجود داشت جلوی ورود دیتای تکراری رو بگیریم ( خطا برگردانیم که این مقدار تکراری است).
این کار، وقتی دارید از Schema در Express Validator استفاده میکنید، میتونه گیج کننده باشه. چون شامل استفاده از چند تکنیک مختلف هست که توضیح هر کدوم در بخش های مختلف داکیومنت Express Validator اومده ، ولی راه حل منسجمی براش ارائه نکرده. این روش ساده در واقع پیاده سازی هر ولیدیشنی هست که async قراره اجرا بشه.
مسئله ای که من باهاش طرف بودم، بررسی وجود فیلد username تکراری، موقع ساخت کاربر توسط ادمین نرم افزار بود. اولین کدی که نوشتم به صورت زیر بود:
در ولیدیشن بالا، تابع findByUsername صدا زده میشه و مقدار درست رو برمیگردونه. خودمم میدونستم کسی منتظر نتیجه اش نیست :) یعنی مقدار true ( سه خط پایین تر) بر میگرده و نتیجه Repository عملا هیچ کاره است. یه کم در داکیومنت های Express Validator گشتم؛ متوجه شدم که راه حلش هست، ولی نه قابل استفاده در Schema هست و نه نحوه پیاده سازیش در Schema به صورت استاندارد توضیح داده شده:
برای همین یک گشتی زدم و متوجه شدم با async await میشه در schema هم کار کرد. کد رو به صورت زیر تغییرش دادم:
در مثال بالا، async رو قبل از تابع options و await رو قبل از صدا زدن Repository گذاشتم. این بار کاملا صبر میکرد، مقدار false رو به عنوان خروجی تابع برمیگرداند (تا اینجای کار چه عالی!!!) و باز هم میرفت کاربر جدید رو با username تکراری میساخت. ضد حال ...
ولی واقعا سخت نیست! مقادیر بازگشتی درست، بجای true و false مقادیر Promise.resolve و Promise.reject هستند. در نظر داشته باشید که Promise.resolve اجباری نیست و بدون اون هم کد کار میکنه (ولی من دوست دارم کامل پیاده کنم):
و اینطوری شد که API ساخت کاربر کامل شد و بررسی میشه که username تکراری در دیتابیس وجود داره یا نه.
:)
