‏وقتی HTML-اول کاربرها رو دو برابر کرد

نویسنده ماجرای یه مشتری رو تعریف می‌کنه: یه شرکتِ خدماتیِ آب/برق که یه مشکل بزرگ داشت. مشتری‌ها برای ثبتِ درخواست یا باید از یه فرمِ قدیمیِ ASP استفاده می‌کردن یا یه فرایندِ دستیِ گرون‌تر رو طی می‌کردن. چون این شرکت یه انحصارِ تحتِ نظارت بود، اگه رضایتِ مشتری از یه حدی (حدوداً ۹۶٪) پایین‌تر می‌اومد، می‌تونست میلیون‌ها پوند جریمه بشه. دوتا تلاشِ قبلیِ گران‌قیمت شکست خورده بودن؛ تو آخریش پیمانکارایی تو یه کشور دیگه یه اپ ری‌اکت ساخته بودن که فقط ۳ روز آنلاین موند و به‌خاطر شکایتِ مشتری‌ها جمع شد.

به گفتهٔ نویسنده اون اپ یه آشفته‌بازار از اسپینرهای لودینگ و استیتِ سراسریِ جاوااسکریپت بود، دسترس‌پذیر نبود، و آپلودِ عکس — که بخشِ حیاتیِ فرم بود — رو سعی می‌کرد همراهِ بقیهٔ داده‌ها تو localStorage ذخیره کنه که فقط ۵ مگابایت ظرفیت داره. نویسنده می‌گه یه نگاه بهش انداخت و به رئیسش گفت نمی‌تونن مالکیتش رو قبول کنن.

نویسنده تصمیمِ جسورانه‌ای گرفت و نسخهٔ جدید رو با Astro و به سبکِ HTML-اول ساخت: جاوااسکریپت وجود داشت، اون هم به شکلِ web component، ولی فقط برای تقویتِ تدریجیِ سایتی که بدونش هم کامل کار می‌کرد. منطقش این بود که این یه خدماتِ عمومیه، باید روی هر دستگاهی و حتی با اتصالِ ضعیف کار کنه، و فرم نباید هیچ‌وقت داده‌ای رو که کاربر وارد کرده گم کنه. نویسنده می‌گه با یه روایت از Terence Eden دربارهٔ زنی که با مرورگرِ ضعیفِ یه PlayStation Portable صفحه‌های ساده‌ی HTMLی GOV.UK رو می‌خوند خیلی تحت‌تأثیر قرار گرفته بود؛ چون اون صفحه‌ها سبک‌ان و روی مرورگرای داغون هم کار می‌کنن.

ساختارِ کار این شد که هر مرحلهٔ فرم خودش یه صفحهٔ جدا بود؛ با زدنِ «بعدی» فرم ارسال می‌شد و اگه API داده رو معتبر تشخیص می‌داد، مرورگر به مرحلهٔ بعد ریدایرکت می‌شد. داده‌ها (و آپلودها) تو هر مرحله روی بک‌اند با یه شناسهٔ یکتای session ذخیره می‌شدن، پس داده گم نمی‌شد — نویسنده می‌گه یه نفر یه ماه بعد از شروع، فرمش رو کامل کرد. این الگوی ارسال-و-ریدایرکتِ قدیمی رو نویسنده به رنسانسِ کوچیکی که Remix به‌ش داده ربط می‌ده، و می‌گه توضیحش به همکارایی که به اپای سنگینِ سمتِ کلاینت عادت داشتن یه‌کم طول کشید.

بزرگ‌ترین دردِسرِ نویسنده اعتبارسنجیِ فرم بود. به گفتهٔ خودش دیده که تیم‌ها ماه‌ها وقت رو سرِ کلنجار با کتابخونه‌های اعتبارسنجیِ React تلف می‌کنن، در حالی که مرورگر خودش یه سیستمِ اعتبارسنجیِ آماده داره. برای همین یه HTML web component ساخت که دورِ هر فرمِ HTML می‌پیچه، اعتبارسنجیِ خودِ HTML رو برمی‌داره و مدرنش می‌کنه: جلوی تولتیپ‌های پیش‌فرضِ مرورگر رو می‌گیره و خطا رو تو المانِ مرتبط با فیلد (از طریقِ aria-errormessage) نشون می‌ده، حین تایپ خطا رو پاک می‌کنه و موقعِ blur و submit دوباره بررسی می‌کنه — همه‌ش زیرِ ۱ کیلوبایت. نویسنده بعداً نسخهٔ عمومیِ این رو با اسمِ validation-enhancer نوشته. طرزِ استفاده‌ش انقدر ساده‌ست که فقط کافیه فرمت رو با تگش بپیچی:

<validation-enhancer>
  <form>
    <label for="my-email">Email</label>
    <input type="email" name="my-email" aria-errormessage="my-email-error" required />
    <div id="my-email-error"></div>
    <button type="submit">Submit</button>
  </form>
</validation-enhancer>

نتیجه‌ش این بود که موقعِ راه‌اندازی، تعدادِ آدمایی که فرم رو کامل می‌کردن دو برابر شد و تیمِ آنالیز اولش نمی‌دونست این کاربرها از کجا اومدن. نکتهٔ ظریف اینه که پکیج‌های آنالیزِ مبتنی بر جاوااسکریپت اصلاً کاربرایی رو که به‌خاطر خطای جاوااسکریپت بیرون می‌افتن نمی‌بینن. نویسنده در آخر می‌گه قبول نیست که کاربرای مرورگرای قدیمی یا اتصالِ بد یا فناوریِ کمکی رو بیرون بندازیم؛ اگه یه اپ روی یه PSP و اتصالِ 3G کار کنه، برای همهٔ کاربرها کار می‌کنه و ۳۰ سالِ دیگه هم هنوز کار می‌کنه.

نکات کلیدی:

• ادعای اصلی: بازنویسیِ فرم به سبکِ HTML-اول (با Astro) تعدادِ تکمیل‌کننده‌های فرم رو یک‌شبه دو برابر کرد.
• هر مرحلهٔ فرم یه صفحهٔ جداست؛ داده و آپلودها تو هر مرحله با شناسهٔ session روی بک‌اند ذخیره می‌شن و گم نمی‌شن.
• جاوااسکریپت فقط برای تقویتِ تدریجیه؛ سایت بدونش هم کامل کار می‌کنه و روی مرورگرای ضعیف و اتصالِ بد دووم می‌آره.
• یه web component سبک (زیرِ ۱KB) به اسمِ validation-enhancer اعتبارسنجیِ خودِ مرورگر رو می‌گیره و مدرن نشونش می‌ده، با fallback به اعتبارسنجیِ مرورگر و بعد بک‌اند.
• آنالیزِ مبتنی بر جاوااسکریپت کاربرایی رو که به‌خاطر خطای JS بیرون می‌افتن نمی‌بینه، پس سودِ این رویکرد تو آمارِ معمول دیده نمی‌شه.