تعمل شركتنا بشكل رئيسي في تطوير المتاجر عبر الإنترنت ونريد مشاركة خبرتنا في تطوير مشروع على مجموعة من VueJS + Nuxt + Laravel.
ستناقش المقالة كيف قررنا تنفيذ المتجر عبر الإنترنت باعتباره SPA: كيف توصلنا إلى هذا ، والصعوبات ، والسهولة.
الموقع الذي سيتم مناقشته هو متجر على الإنترنت كلاسيكي تقريبًا مع كتالوج ، وفلاتر ، وبحث ، وسلة ، وحساب شخصي ، أي تقريبا كل ما يمكن أن يكون في المتجر. يحتوي المشروع على منطق مختلف وتسعير وخرائط للكيانات القانونية والأفراد.
لماذا سبا
قبل المشروع الحالي ، كانت خبرتنا في تطوير تطبيقات الصفحة الواحدة تتكون من عدد قليل من المشاريع الداخلية فقط. ومن نواح عديدة ، كان سبا بالنسبة لنا ، إلى حد ما ، حصانًا أسود.
لم يكن هناك فهم واضح للمشاكل المرتبطة بنمو المشروع ، وتعزيز سيو واستقراره ، عندما لم يثروا ، كخبرة وعمليات طويلة الأمد في إنشاء المواقع العادية ، أي أسئلة في حل هذه المشاكل.
تسبب اختيار النهج في جدال ساخن تمامًا في شركتنا ، حيث تم ملء المقاييس والحجج وكان القرار صعبًا للغاية. قرر مطورونا جمع نموذج أولي لعدة صفحات من المشروع ومعرفة الصعوبات التي ستنشأ مع كل نهج. ساعدنا هذا النهج في الحل النهائي. ساعدت النماذج الأولية على إظهار أن إدارة حالة الموقع (الكتالوج ، السلة ، الخروج ، إلخ) أكثر راحة بكثير وتسبب مشاكل أقل في إصدار SPA. لقد زادت سرعة التطوير والتفاعل بين المطابع والمبرمجين بشكل ملحوظ نظرًا لأنك لست بحاجة إلى نقل التخطيط ، فما عليك سوى إضافة المنطق إلى المكونات الجاهزة. كما أصبحت المشكلات التي قد نواجهها أكثر وضوحًا مما دفع إلى اتخاذ المزيد من الإجراءات. قبلنا كان اختيار التكنولوجيا.
خارج النافذة هو صيف 2017. على تويتر وعلى الوسيط ، لا تهدأ النزاعات ، والتي لا تزال أفضل ، أو تتأثر أو تتفاعل. مكتبنا لم يجتاز هذا الاتجاه. انقسم المطورون أيضًا إلى معسكرين ، لكل منهما حججه الخاصة. قبل ذلك ، عمل كل منا بالفعل مع كلتا التقنيتين.
أصبح شخص ما أقرب إلى jsx ، ويفضل شخص ما HTML أو الصلصال المألوف أكثر ، يعتقد شخص ما أن الثبات يساعد على مراقبة حالة التطبيق والتحكم فيها بشكل أفضل ، بالنسبة لشخص ما يبدو وكأنه تعقيد مفرط. من ناحية أخرى ، يمنحنا كل إطار عمل الفرصة لإنشاء مكونات أحادية الملف ، ولدى كليهما بالفعل مكتبات مستقرة تمامًا مع مجموعة من جميع الوظائف الضرورية لنا (ssr ، إدارة الحالة العالمية ، التوجيه ، إدارة البيانات الوصفية). للتفاعل هو nextjs ، و vue هو nuxtjs. Nuxt في وقت الاختيار كان لا يزال في مرحلة تجريبية ، ولكنه مستقر تمامًا. لأن تم بناء عملية التطوير بطريقة أصبح لدينا تخطيطًا مبدئيًا ، ثم قمنا ببناء جزء الواجهة الخلفية ونقل تخطيط الصفحات إلى الواجهة الأمامية ، كان اختيار الإطار بسيطًا جدًا. لقد اخترنا vue و nuxtjs ، لأنه تقرر إنشاء الموقع وإطلاق واجهة برمجة التطبيقات بالتوازي. مع هذا النهج ، من المناسب تكوين المكونات على الفور وإضافة المنطق إليها. اتخذ مصممو التخطيط لدينا نهجًا أوثق لإنشاء HTML المعتاد.
قليلا عن الخلفية
من حيث حلول الخوادم وبشكل عام اختيار التقنيات لبناء الواجهة الخلفية ، فقد سلكنا الطريقة المألوفة أكثر. تم اختيار اللغة php ، والتي نستخدم لها إطار Laravel. كل ذلك يدور على nginx. كحل لقاعدة البيانات لدينا الخلية.
بداية التطوير ، الحزم والمشكلات المستخدمة
يوفر Nuxt حزمًا مرضية تمامًا لنا لإدارة حالة التطبيق (vuex) والتوجيه (vue-router). لذلك ، يمكن البدء فورًا في تجميع المشروع وتثبيت المنطق للمكونات على الفور ، ثم ، حسب الحاجة ، ابحث عن الحزم التي نحتاجها. بادئ ذي بدء ، كنت بحاجة إلى حل للتواصل مع الجزء الخلفي. للقيام بذلك ، تم اختيار المحاور ، وهو المعيار القياسي بالفعل للجميع ، ومجمع وحدة المحاور nuxt-axios فوقها. نساعد أيضًا على الفور المشروع على عدم الضياع في البيئة والتشغيل في كل بيئة باستخدام التكوين المطلوب - حدد dotenv و nuxt-dotenv-wrapper module. لبدء التطوير ، هذا يكفي وبدأت عملية التخطيط.
حدث التوقف الأول عندما كان من الضروري إضافة منزلق صورة إلى التخطيط. تم سماع "أين هو منزلق البقعة ، أريد مسج" من جانب التصميم في الغرفة. كشفت مراجعة سريعة للحلول الجاهزة عن عدة منزلقات مناسبة لنا. لكن الجميع تقريبًا جروا اعتمادًا على شكل مسج ، والذي لم أرغب في إضافته إلى الحزمة النهائية ، وبالتالي زيادة حجمه. لم تدعم بعض الحزم تقديم الخادم ، وهو أمر مهم أيضًا بالنسبة لنا. نتيجة لذلك ، وقع الاختيار على swiper-swiper ، التي استوفت متطلباتنا بالكامل وحتى أكثر قليلاً. بعد تثبيت شريط التمرير ، ظل مصممو التخطيط في حيرة لفترة طويلة. "هل هذا كل شيء ، هل علي فعل أي شيء آخر؟ ما عليك سوى تحديد قائمة بالصور وهي تعمل؟ "
بعد ذلك جاء اختيار المكون لاختيار التواريخ. كان هناك المزيد من الحظ تم العثور بسرعة على غلاف لمسطح الحبيبة لدينا. كل ما تبقى هو تصميمه قليلاً.
في عدة أماكن على الموقع توجد خريطة. لكن لأن لم نكن بحاجة إلى تفاصيل كاملة وتفصيل للخريطة ، ولم يكن هناك خيار بين الخدمات. ومع ذلك ، في وقت التطوير ، وحتى الآن ، لا توجد حلول تغطي جميع احتياجاتنا بشكل مثالي. استنادًا إلى جميع الإيجابيات والسلبيات ، تم اختيار خرائط google ومجمع vue2-google-خرائط. الحزمة كبيرة بما يكفي وتجذب الكثير من الأشياء غير الضرورية لنا ، لكنها تحل مشاكلها بشكل جيد.
في بعض الأشكال ، لدينا حقول لإدخال الهاتف. يحتاج المستخدم للمساعدة في إدخال الهاتف ، حيث أن هناك العديد من الخيارات للتنسيق ، ومن ثم يصبح العمل في المستقبل باستخدام البيانات التي يتم إدخالها بتنسيق واحد أسهل. لذلك ، تحتاج إلى قناع. كنت أرغب في استخدام قناع النص المألوف بالفعل ، وهنا كنا محظوظين ، فقد كان لديهم بالفعل حل لـ vue - vue-text-mask.
غطت هذه الحزم جميع متطلباتنا تقريبًا. كل ما تبقى هو تتبع النقرات خارج المكوّن ، الأمر الذي ساعد على النقر خارجًا. قمنا بتنفيذ التمرير السريع لأعلى الصفحة باستخدام vue-backtotop. للعمل مع التواريخ ، استخدم اللحظة.
حجم الحزمة النهائي ومن أين أتى 1 ميجابايت
يجب أن يوضع في الاعتبار أن المعيار الهام عند اختيار الحزم هو وزنها.
في منتصف المشروع ، قررنا تحليل المشروع النهائي ومعرفة أبعاد التجميع. كانت النتائج ، بعبارة ملطفة ، مفاجئة. كان حجم عصابة app.js يزيد قليلاً عن 950 كيلوبايت. جلب لنا فريق تحليل npm run رسمًا بيانيًا جميلًا بحجم جميع الوحدات ، والتي أدركنا منها أن بعض الوحدات تسحب تبعيات غير ضرورية في شكل jquery ، و Lodash ، وما إلى ذلك. كان عليهم رفض هذه الحزم وإيجاد بديل لها. حاليًا ، يبلغ حجم الحزمة بأكملها 480 كيلوبايت.
راقب التبعيات وتحقق دوريًا من حجم تطبيقك.
صفحة التحميل الأولي والبيانات التي تم الحصول عليها بواسطة api
يوفر Nuxt فرصة مناسبة لملء المخزن بالبيانات من جانب الخادم قبل تحميل العميل. لهذا ، يتم استخدام الإجراء nuxtServerInit. يبدو لنا هذا مثل:
نظرًا لأننا نستخدم الفئات وبعض الكيانات الأخرى في العديد من المكونات في وقت واحد ، فقد كان أكثر ملاءمة بالنسبة لنا الحصول عليها فورًا ووضعها في المتجر.
ولكن هنا توجد مشكلة مع حجم json الذي تحصل عليه. نظرًا لأن الخادم يرسل جميع البيانات المستلمة إلى العميل للعرض الأولي ، فقد يكون حجم html كبيرًا جدًا. اكتشفنا هذا عندما بدأنا في الفئات بنقل الصور والأوصاف والحقول الأخرى التي لم تكن ضرورية لنا في جميع الصفحات التي تنتمي إلى كل فئة. كان حجم json أكثر من 2 ميغابايت. لحسن الحظ ، يمكن إصلاح ذلك بسهولة عن طريق إزالة الحقول غير الضرورية من البيانات التي يقدمها الخادم.
تسرب الذاكرة
بعد مرور بعض الوقت ، بدأ التطبيق على خادم الاختبار لدينا بمراقبة زيادة غير طبيعية في استهلاك الذاكرة. احتلت pm2 ما يصل إلى 90٪ من ذاكرة الخادم وتعطل التطبيق بشكل دوري. على صفحة github nuxt علقت بالفعل
مشكلة قليلة مع نفس المشكلة.
نشأت المشكلة عندما قدمنا عدة طلبات في طريقة asyncData لصفحاتنا.
لحسن الحظ ، حل المطورون التاليون هذه المشكلة بسرعة ، وتستهلك العملية حاليًا حوالي 40 ميغابايت من الذاكرة.
مشاكل مثيرة للاهتمام وحلولها
مقالات مكونةفي لوحة تحكم الموقع ، من الممكن إضافة مقالات وإدراج كتل متنوعة في محتوى المقالة ، على سبيل المثال ، كتلة تحتوي على سلع.
يبدو HTML الذي يأتي من الخادم كالتالي:
يشير $ product-4 إلى أن مكوِّن Product.vue بالمعرف 4 يجب أن يكون مكان هذا المؤشر. تزودنا Vue بإمكانيات واسعة لتقديم المكون باستخدام طريقة التجسيد. أولاً ، نبحث عن جميع الإشارات إلى المؤشرات إلى المكونات في html التي وصلنا ونحصل عن طريق api على البيانات اللازمة لعرض هذا المكون. بعد ذلك ، قمنا بتقسيم html بالكامل إلى شجرة. ساعدتنا مكتبة الهيمالايا في ذلك. ثم نجمع html مرة أخرى عن طريق استبدال المؤشرات بمكونات جاهزة.
... ولم يكن هناك ما يكفي من القوة لكتابة مقال) بدأوا في كتابة المقال في صيف عام 2017 أثناء تطوير المشروع ، وقد كان بالفعل صيف 2018 في الفناء ، تم إطلاق المشروع ولم يتم نشر المقالة.
لذلك ، ننشر ما جمعناه ، ولكن لا يزال لدينا العديد من الموضوعات والملاحظات المثيرة للاهتمام.
إذا كان الأمر مثيرًا للاهتمام - اكتب ، مثله)) حسنًا ، ماذا سيكون من المثير للاهتمام أن نسمع عنه ، الذي فاتك.
أريد أن أقول إن المشروع يعمل منذ حوالي 4 أشهر. لم تكن هناك مشاكل خاصة به ، وسرعة الموقع مذهلة وتميزه عن المتاجر الأخرى.