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