✍️ در پروژه پایانی، یک گزارش از سفارش‌های فروشگاه می‌سازیم. اولین مرحله محاسبه جمع نیست؛ باید مطمئن بشیم هر ردیف شکل مورد انتظار را دارد. اگر بررسی ورودی را به بعد موکول کنیم، یک رشته به جای مبلغ می‌تونه کل گزارش را به متن تبدیل کنه یا یک نام خالی، مشتری ساختگی بسازه.
مثال متفاوت: ردیف {status:'paid',customer:' آوا ',total:40} بعد از یکسان‌سازی به نام «آوا» می‌رسه. فاصله‌های ابتدا و انتهای نام نشانه مشتری تازه نیستند. در مقابل total برابر رشته '40' را حدس نمی‌زنیم و تبدیل نمی‌کنیم؛ چنین ردیفی باید رد بشه.
قرارداد داده در تمام پروژه ثابت است: orders اگر آرایه نباشد، داده‌ای نداریم. هر ردیف معتبر باید شیء غیرnull و غیرآرایه باشد؛ status دقیقاً 'paid' یا 'cancelled'، customer رشته‌ای با trim غیرخالی و total عدد واقعی متناهی نامنفی باشد. نام مشتری با trim یکسان‌سازی می‌شود؛ حروف بزرگ و کوچک متفاوت‌اند. ویژگی اضافه مجاز است. ردیف نامعتبر نادیده گرفته می‌شود و چیزی در ورودی تغییر نمی‌کند.
اینجا سفارش لغوشده معتبر هم در خروجی باقی می‌مونه؛ حذف آن مربوط به مرحله بعد است. خطای رایج، قاطی کردن معتبر بودن داده با قابل محاسبه بودن در درآمد است. نتیجه را از شیءهای تازه با فقط سه ویژگی مشخص بساز تا ویژگی اضافه یا فاصله نام، وارد مراحل بعد نشه.
فعالیت شما
normalizeOrders(orders) را کامل کن. قرارداد داده در تمام پروژه ثابت است: orders اگر آرایه نباشد، داده‌ای نداریم. هر ردیف معتبر باید شیء غیرnull و غیرآرایه باشد؛ status دقیقاً 'paid' یا 'cancelled'، customer رشته‌ای با trim غیرخالی و total عدد واقعی متناهی نامنفی باشد. نام مشتری با trim یکسان‌سازی می‌شود؛ حروف بزرگ و کوچک متفاوت‌اند. ویژگی اضافه مجاز است. ردیف نامعتبر نادیده گرفته می‌شود و چیزی در ورودی تغییر نمی‌کند. خروجی آرایه ردیف‌های معتبر با فقط {status,customer,total} و ترتیب اولیه است، شامل cancelled. [{status:'paid',customer:' آوا ',total:0}] => [{status:'paid',customer:'آوا',total:0}]؛ نبود داده => []. تابع کمکی آماده checkNormalizeOrdersUnchanged فقط تغییر نکردن ورودی و، هرجا لازم است، تازه بودن خروجی را بررسی می‌کند؛ آن را تغییر نده.