من بين الأشياء التي جعلتنا في حيرة من أمرنا عندما كنا نبني موقعنا الإلكتروني الجديد هي الأمواج المتغيرة التي يمكنك رؤيتها في أماكن مختلفة على الصفحات. كان لدينا العديد من الأفكار حول كيفية تنفيذها بالطريقة الصحيحة دون بذل جهد كبير. ومع ذلك، كانت معظم الحلول بطيئة وكان علينا أن نبني من الصفر شيئًا أسرع من المكتبات الموجودة بالفعل.
مقترحات الحلول
بدأنا بكائن SVG عادي تم تحريكه باستخدام مكتبات مختلفة. وبما أننا أردنا الحصول على 3 كائنات في صفحة واحدة، لم تكن النتيجة مرضية. كانت جميع الرسوم المتحركة بطيئة - كان يجب تحديث جميع مسارات كائن SVG واحد في فترات زمنية قصيرة جدًا، مما جعل الصفحة بأكملها بطيئة مثل الحلزون. اضطررنا إلى رفض الحل باستخدام SVG النقي المدرج في مستند. ترك لنا ذلك حلين آخرين للاختيار من بينهما.
إن فيديو
كان العنصر هو الخيار الثاني. بدأنا بمشكلتين:
- خلفية شفافة، والتي لا يمكن تطبيقها مع تنسيقات الفيديو الأكثر شيوعًا مثل .mp4 أو .webm,
- الاستجابة، والتي كانت مشكلة حقيقية لأن مقاطع الفيديو غير قابلة للتطوير على هذا النحو.
قررنا أن نبقي هذا الحل في الخلفية - "إذا لم نجد حلاً آخر، سنختار هذا الحل".
كان الخيار الأخير هو استخدام اللوحة القماشية
مع WebGL
التقديم. كان خيارًا غير عادي لأننا اضطررنا إلى تصميم جميع آليات العرض بأنفسنا. وذلك لأن الموجات المورفولوجية التي لدينا كانت موجات مخصصة - مما أجبرنا على تصميم حل مخصص وكان هذا هو الخيار الذي أردنا اتباعه والتركيز عليه حقًا.
بنية الحل
لنبدأ من الصفر. ما هي المادة التي كان علينا استخدامها لبناء هذه الأمواج؟ كانت الفكرة أن كل الموجات كانت عبارة عن ملف SVG بحجم 1×1 ومسارات محددة موضوعة حول هذه المنطقة. تم بناء الرسوم المتحركة لـ SVG هذا من خلال بعض أشكال الحالات لهذا الملف. لذا، تم تمثيل جميع الرسوم المتحركة كمجموعة من الملفات التي تحتوي على مراحل تحريك الشكل.
ألقِ نظرة أعمق على ماهية الحالات - جميع المسارات هي مجرد نوع من مصفوفة ذات قيم محددة موضوعة في مواضع محددة. يؤدي تغيير تلك القيم في مواضع محددة داخل هذه المصفوفة إلى تغيير الشكل في أجزائها المحددة. يمكننا تبسيط ذلك بالمثال التالي:
الحالة 1: [1، 50، 25، 40، 100]
الحالة 2: [0، 75، -20، -20، 5، 120]
الحالة 3: [5، 0، -100، 80، 90]
لذا، يمكننا أن نفترض أن الشكل الذي نريد تصييره يتكون من مصفوفة ذات 5 عناصر تتغير مع التيسير الخطي في فترات زمنية محددة. عندما تنتهي الرسوم المتحركة من المرحلة الأخيرة، تبدأ من جديد بالمرحلة الأولى لتعطينا انطباعًا بأن الرسوم المتحركة لا نهائية.
ولكن... انتظر - ما هي المصفوفة المعروضة أعلاه بالضبط؟ كما ذكرت، إنه مسار مسؤول عن عرض شكل معين. يتم تضمين كل السحر في d
لمسار SVG. تحتوي هذه الخاصية على مجموعة من "الأوامر" لرسم شكل وكل أمر يحتوي على نوع من الوسيطات. تتكون المصفوفة المذكورة أعلاه من جميع القيم (الوسيطات) المرفقة بهذه الأوامر.
كان الاختلاف الوحيد بين "ملفات الحالة" هذه هو قيم الأوامر المحددة حيث كان ترتيب الأوامر واحدًا. لذا، كان كل السحر يتعلق بالحصول على جميع القيم وتحريكها.
المعالج المسمى بالفيزياء
في الفقرة أعلاه، ذكرت أن السحر الوحيد في تحريك جسم ما هو إنشاء انتقالات بين جميع مراحل الشكل. السؤال هو - كيف نفعل ذلك باستخدام اللوحة القماشية؟
الوظيفة التي يعمل بها كل من عمل مع اللوحة القماشية
يجب أن يعرف هو طلب محاكاة الإطار. إذا كنت ترى هذا لأول مرة، أعتقد بصدق أنه يجب أن تبدأ بقراءة هذا. إذن، الشيء الذي يهمنا في هذه الدالة هو الحجة - DOMHighResResTimeStamp
. يبدو الأمر مرعبًا حقًا ولكن عمليًا ليس من الصعب فهمه. يمكننا أن نقول أنه طابع زمني للوقت المنقضي من أول عملية تصيير.
حسناً، ولكن ماذا يمكننا أن نفعل بهذا؟ بما أن طلب محاكاة الإطار
يجب أن تُستدعى الدالة بشكل متكرر، يمكننا الوصول إلى دالة زمنية بين استدعاءاتها. وهنا نذهب مع العلم! ⚛️ (حسنًا، ربما ليس علم الصواريخ... بعد)
تعلمنا الفيزياء أن دلتا المسافة تساوي دلتا الزمن مضروبة في السرعة المتجهة. في حالتنا هذه، السرعة المتجهة ثابتة لأننا نريد الوصول إلى نقطة النهاية في فترة زمنية محددة. لذا، دعونا نلقي نظرة على كيفية تمثيل ذلك بالحالتين السابقتين:
لنفترض أننا نريد الانتقال بين هذه الحالات خلال ألف مللي ثانية، لذا ستكون قيم السرعة المتجهة كالتالي:
دلتا: [ -1، 25، -45، -35، -35، 20]
السرعة: [-1/1000/1000، 25/1000، -45/1000، -35/1000، 20/1000]
تخبرنا السرعة المتجهة أعلاه: لكل مللي ثانية دعنا نزيد القيمة بمقدار -1/1000. وهذه هي النقطة التي يمكننا العودة فيها إلى طلب محاكاة الإطار
ودلتا الزمن. قيمة الموضع المحدد الذي نريد زيادته هي دلتا الزمن مضروبة في سرعة موضعه. هناك شيء آخر لتحقيق ذلك دون مشكلة، وهو تحديد القيمة بحيث لا تتجاوز الحالة التي ستنتقل إليها.
وعندما تنتهي الفترة الانتقالية، ننادي بفترة انتقالية أخرى وهكذا. ولا يبدو من الصعب تنفيذ ذلك ولكن إحدى القواعد الرئيسية في تطوير البرمجيات هو عدم قضاء الوقت في أشياء تم تنفيذها بالفعل. لذلك - اخترنا مكتبة صغيرة التي تسمح لنا بإنشاء هذه التحولات بطريقة سهلة.
هكذا أنشأنا موجة متحركة واحدة تبدو وكأنها كائن حي.
بضع كلمات عن أشكال الاستنساخ
كما ترى، فإن موجات العلامة التجارية The Codest ليست مجسمًا متحركًا واحدًا. فهي تتكون من العديد من الأشكال بنفس الشكل ولكن بحجم وموضع مختلفين. في هذه الخطوة، سنلقي نظرة سريعة على كيفية التكرار بهذه الطريقة.
لذا، يتيح لنا سياق اللوحة القماشية مساحة الرسم بمقياس الرسم (تحت الغطاء - يمكننا القول أنه يضاعف جميع الأبعاد التي تم تمريرها إلى الطرق القابلة للرسم ب "k"، حيث "k" هو عامل قياس، يتم تعيينه افتراضيًا على "1"), جعل اللوحة القماشية مترجمةفهو يشبه تغيير نقطة الارتكاز في منطقة الرسم. ويمكننا أيضًا الانتقال بين هذه الحالات بهذه الطرق: احفظ و الاستعادة.
تسمح لنا هذه الطرائق بحفظ حالة "التعديلات الصفرية" ثم تصيير عدد محدد من الموجات في الحلقة مع لوحة قماشية متدرجة ومترجمة بشكل صحيح. بعد ذلك مباشرةً، يمكننا العودة إلى الحالة المحفوظة. هذا كل ما يتعلق باستنساخ الأشكال. أسهل بكثير من استنساخ الخراف، أليس كذلك؟
كرز على القمة
لقد ذكرت أننا رفضنا أحد الحلول المحتملة بسبب الأداء. الخيار مع القماش سريع جدًا ولكن لم يقل أحد أنه لا يمكن تحسينه أكثر من ذلك. لنبدأ بحقيقة أننا لا نهتم حقًا بنقل الأشكال عندما تكون خارج إطار عرض المتصفح.
هناك واجهة برمجة تطبيقات أخرى للمتصفح أحبها المبرمجون - مراقب التقاطع. يسمح لنا بتتبع عناصر محددة من الصفحة والتعامل مع الأحداث التي يتم استدعاؤها عند ظهور تلك العناصر أو اختفائها من منفذ العرض. الآن - لدينا الآن - لدينا حالة سهلة جدًا - دعنا ننشئ حالة الرؤية، ونغيرها بسبب معالجات أحداث IntersectionObserver ونقوم ببساطة بتشغيل/إيقاف نظام التصيير لأشكال محددة. و ... تحسن الأداء كثيرًا! نحن نُصيِّر الأشياء المرئية فقط في منفذ العرض.
الملخص
غالبًا ما يكون اختيار طريقة لتنفيذ الأمور خيارًا صعبًا، خاصةً عندما تبدو الخيارات المتاحة متشابهة في المزايا والعيوب. مفتاح الاختيار الصحيح هو تحليل كل منها واستبعاد تلك التي نراها أقل فائدة. ليس كل شيء واضحًا - فبعض الحلول تتطلب وقتًا أطول من الحلول الأخرى ولكن قد يكون تحسينها أسهل أو أكثر قابلية للتخصيص.
على الرغم من ظهور مكتبات JS جديدة كل دقيقة تقريبًا، إلا أن هناك أمورًا لا تستطيع حلها. ولهذا السبب يجب على كل مهندس واجهة أمامية (وليس هم فقط) أن يعرف واجهات برمجة التطبيقات الخاصة بالمتصفح، وأن يواكب الأخبار التقنية ويفكر أحيانًا "كيف سيبدو تطبيقي لهذه المكتبة إذا اضطررت إلى القيام بذلك؟ بمزيد من المعرفة حول المتصفحات، يمكننا بناء أشياء رائعة حقًا، واتخاذ قرارات جيدة بشأن الأدوات التي نستخدمها، ونصبح أكثر ثقة بشأن الكود.
اقرأ المزيد:
– روبي 3.0 روبي وطرق التحكم في الخصوصية الأقل شهرة
– اخرس وخذ نقودك #1: التكاليف الخفية والرشاقة الحقيقية في عملية تطوير المنتج
– CTO التحديات - توسيع نطاق ونمو منتجات البرمجيات