لماذا تحتاج تطبيقات الجداول إلى بريدي الإلكتروني؟ قمت ببرمجة بديل 100% Client-Side 📅🚀

لنكن صريحين. هل حاولت يوماً البحث عن تطبيق ويب بسيط لإنشاء جدول محاضرات أسبوعي؟

عادةً ستواجه أحد هذين السيناريوهين:

قالب إكسل (Excel) قديم ومزعج جداً عند التصفح من الجوال.

تطبيق "حديث" يطلب بريدك الإلكتروني، ويجبرك على تفعيل الحساب، ثم يفاجئك بـ Paywall (اشتراك مدفوع) فقط لكي تقوم بتصدير جدولك كصورة.

كل هذا العناء من أجل ترتيب 5 أو 6 مواد جامعية خلال الأسبوع!

كمطور، وجدت هذا الأمر غير منطقي. تطبيق الجداول الأسبوعية لا يحتاج إلى Backend ثقيل، أو نظام مصادقة (Auth)، أو قاعدة بيانات. لذلك، قررت بناء صانع الجداول الجامعية لمنصة أدواتي — أداة سريعة جداً، تعمل 100% في متصفح العميل (Client-Side) بدون أي سيرفرات خلفية.

إليكم كيف قمت ببنائها والتحديات التقنية التي تجاوزتها باستخدام الـ Web APIs القياسية. 🛠️

🚫 نهج "اللا قاعدة بيانات" (إدارة الحالة محلياً)
عندما تبني تطبيقاً بدون قاعدة بيانات، السؤال الأول الذي يتبادر للذهن هو: كيف نحفظ بيانات المستخدم حتى لا يفقدها إذا قام بتحديث الصفحة (Refresh)؟

اعتمدت بشكل كبير على واجهة localStorage API.
كلما قام المستخدم بإضافة مادة، يقوم التطبيق بتحديث مصفوفة (Array) تمثل الجدول، ويحولها إلى نص باستخدام JSON.stringify، ثم يحفظها محلياً. وعند تحميل الـ DOM، يتحقق التطبيق من الـ localStorage، ويقرأ الـ JSON، ويحدث واجهة المستخدم (UI) في أجزاء من الثانية.

النتيجة؟ يحصل المستخدم على تجربة "الحفظ التلقائي" (Auto-save) المطابقة تماماً للتطبيقات السحابية، ولكن جدوله الأكاديمي لا يغادر جهازه الفعلي أبداً. خصوصية مطلقة، وتكلفة سيرفرات 0$ بالنسبة لي كمطور.

⏱️ اكتشاف التعارض الزمني في المتصفح
إذا أضفت محاضرة يوم الإثنين من الساعة 09:00 إلى 10:30، لا ينبغي أن يسمح لك النظام بإضافة محاضرة أخرى يوم الإثنين تبدأ الساعة 10:00.

بدلاً من إرسال طلب HTTP إلى السيرفر للتحقق من هذا التعارض الزمني، كتبت خوارزمية تحقق خفيفة تعمل مباشرة في المتصفح.
لتسهيل العمليات الحسابية، يحول التطبيق جميع الأوقات إلى "دقائق من منتصف الليل". وقبل حقن المادة الجديدة في الـ DOM، تمر الخوارزمية على المواد الموجودة في نفس اليوم وتتحقق من شرط التداخل الزمني:

وقت البداية الجديد < وقت النهاية الموجود && وقت النهاية الجديد > وقت البداية الموجود

إذا تحقق الشرط، تظهر واجهة المستخدم تحذيراً فورياً. وبسبب عدم وجود تأخير في الشبكة (Zero Network Latency)، فإن الاستجابة تكون أسرع من البرق.

🖼️ التحدي الأخير: تحويل الـ DOM إلى صورة PNG عالية الدقة
الميزة الأولى التي يطلبها الطلاب هي القدرة على تحميل جدولهم كصورة لاستخدامها كخلفية لشاشة القفل في هواتفهم الذكية.

تحويل تصميم HTML/CSS معقد (Grids, Flexbox, ونصوص مخصصة) إلى صورة قابلة للتحميل أمر صعب برمجياً. استخدمت Canvas API لأخذ "لقطة" (Snapshot) للـ DOM.
لكن إذا قمت بذلك من قبل، فستعرف أن الصورة الناتجة غالباً ما تكون ضبابية (Blurry)، خاصة على شاشات الهواتف الحديثة (Retina Displays).

الحل التقني: قمت برمجياً بإجبار الـ Canvas على التصيير (Render) بدقة 3x (ثلاثة أضعاف الدقة العادية) قبل إنشاء رابط البيانات (Base64 data URL). النتيجة هي صورة PNG فائقة الدقة يتم تحميلها مباشرة لجهاز المستخدم بدون أي طلب للسيرفر.

👉 جربها بنفسك!
إذا كنت تريد أن ترى مدى سلاسة تطبيقات الـ Client-side 100%، جرب بناء جدول سريع (وحاول أن تتعمد إحداث تعارض زمني لتختبر سرعة الخوارزمية) من هنا:
صانع الجداول الجامعية - أدواتي

سؤال لمجتمع المطورين: هل سبق لكم العمل بمكتبات تحويل الـ DOM إلى صور (مثل html2canvas)؟ وكيف تعاملتم مع مشكلة النصوص الضبابية أو اختلافات الـ CSS بين المتصفحات؟ شاركوني تجاربكم في التعليقات! 👇