‏۹ چک قبل از فرستادن ایمیل محصول

نویسنده این مقاله تو SitePoint با مثال یه ایمیل دعوت به workspace نشون می‌ده که ایمیل محصول از چند جا می‌تونه خراب بشه: طراحی، کد HTML، منطق بک‌اند و مرحله تحویل. اولین قدم به گفته اون نوشتن یه «قرارداد رفتاری» کوتاهه، یعنی لیست چیزایی که ایمیل حتماً باید انجام بده. مثلاً گیرنده بفهمه کی دعوتش کرده، لینک قبول بدون لود شدن عکس‌ها هم قابل فهم باشه و نسخه plain-text هم همون اطلاعات رو بده. بعدش برای حالت‌های مختلف fixture بسازین: اسم workspace کوتاه و بلند، اسم با حروف خاص و نسخه ترجمه‌شده.

برای ساخت قالب، ابزارهایی مثل MJML یا React Email معرفی می‌شن، ولی نویسنده می‌گه یکی رو انتخاب کنین و حتماً HTML نهایی که تولید می‌شه رو هم بررسی کنین، چون ممکنه با کامپوننت اصلی خیلی فرق داشته باشه. یه نکته مهم هم اینه که پشتیبانی مرورگر با پشتیبانی کلاینت ایمیل یکی نیست. برای همین با سایت Can I Email ویژگی‌های CSS و HTML رو چک کنین و یه لیست کوچیک از کلاینت‌های دقیق (نه فقط «Outlook») داشته باشین. تو بخش دسترس‌پذیری هم توصیه می‌شه متن اصلی تو عکس نباشه و لینک‌ها اسم توضیحی داشته باشن، نه «اینجا کلیک کنید».

قدم بعدی اینه که ایمیل واقعی‌ای که برنامه می‌سازه رو با Mailpit (یه سرور SMTP محلی برای تست) بگیرین و گیرنده، موضوع، encoding و توکن دعوت رو چک کنین. نویسنده هشدار می‌ده که link checker ممکنه یه توکن یه‌بارمصرف رو مصرف کنه. برای جلوگیری از لینک‌های اشتباه هم یه تابع اعتبارسنجی پیشنهاد می‌ده که پروتکل، hostname و مسیر لینک رو قبل از گذاشتن تو قالب بررسی می‌کنه:

function validateInvitationUrl(raw) {
  const url = new URL(raw);
  if (
    url.protocol !== "https:" ||
    url.hostname !== "app.example.com" ||
    url.pathname !== "/invitations/accept"
  ) {
    throw new Error("Unexpected invitation destination.");
  }

این تابع فقط شکل URL رو چک می‌کنه، نه اعتبار توکن یا تاریخ انقضاش رو؛ اونا رو خود اپلیکیشن باید بررسی کنه. کد کامل مقاله تعداد توکن‌ها و پارامترهای اضافه رو هم چک می‌کنه و با node --test اجرا می‌شه.

برای تست ظاهر، Playwright برای چک‌های تکرارپذیر روی پیش‌نمایش HTML خوبه، ولی رفتار واقعی کلاینت‌های ایمیل رو شبیه‌سازی نمی‌کنه. پس باید از سرویس‌هایی مثل Litmus یا اکانت‌های تست واقعی هم استفاده کنین. نویسنده می‌گه آپدیت اسکرین‌شات‌ها رو هیچ‌وقت خودکار قبول نکنین، چون ممکنه یه باگ واقعی رو قایم کنن.

آخر سر نوبت به رفتار پس‌زمینه می‌رسه. چون ایمیل معمولاً تو یه background job ساخته می‌شه، باید retry، انقضای دعوت، لغو دسترسی و webhookهای تکراری تست بشن. به گفته نویسنده یه فلگ «sent» تو دیتابیس تضمین ارسال دقیقاً یه‌باره نیست، چون اگه برنامه بین قبول شدن توسط provider و ذخیره فلگ کرش کنه، وضعیت مبهم می‌شه. بعد از اون هم باید احراز هویت فرستنده، bounceها و قوانین providerهایی مثل Gmail رو بررسی کرد.

نکات کلیدی:

• یه قرارداد رفتاری کوتاه بنویسین و طراحی رو با fixtureهای واقعی مثل اسم‌های بلند و ترجمه‌شده تست کنین.
• MJML یا React Email، فقط یکی؛ و HTML کامپایل‌شده رو حتماً بررسی کنین.
• پشتیبانی مرورگر با پشتیبانی کلاینت ایمیل فرق داره؛ Can I Email برای چک ویژگی‌ها کمک می‌کنه.
• Mailpit ایمیل واقعی برنامه رو محلی می‌گیره، ولی link checker نباید توکن یه‌بارمصرف رو مصرف کنه.
• Playwright رندر کلاینت ایمیل رو شبیه‌سازی نمی‌کنه؛ برای اون Litmus یا اکانت تست لازمه.
• فلگ «sent» تو دیتابیس ارسال دقیقاً یه‌باره رو تضمین نمی‌کنه.