تصميم وبناء تطبيق ويب تقدمي بدون إطار (الجزء 3)

بالعودة إلى الجزء الأول من هذه السلسلة ، أوضحنا سبب ظهور هذا المشروع. وهي الرغبة في معرفة كيفية إنشاء تطبيق ويب صغير في Vanilla JavaScript والحصول على مطور غير مصمم يعمل على أجزاء التصميم الخاصة به قليلاً.

في الجزء الثاني ، أخذنا بعض التصميمات الأولية الأساسية وقمنا بإعداد الأمور وتشغيلها باستخدام بعض خيارات الأدوات والتكنولوجيا. قمنا بتغطية كيف ولماذا تغيرت أجزاء من التصميم وعواقب تلك التغييرات.

في هذا الجزء الأخير ، سنغطي تحويل تطبيق ويب أساسي إلى تطبيق ويب تقدمي (PWA) و "شحن" التطبيق قبل النظر في الدروس الأكثر قيمة المستفادة من خلال جعل تطبيق الويب البسيط In / Out:

• القيمة الهائلة لطرق مصفوفة JavaScript ؛
• تصحيح
• عندما تكون المطور الوحيد ، فأنت المطور الآخر ؛
• التصميم هو تطوير.
• قضايا الصيانة والأمن الجارية ؛
• العمل في مشاريع جانبية دون أن تفقد عقلك أو دافعك أو كليهما ؛
• شحن بعض المنتجات يتفوق على شحن أي منتج.

لذا ، قبل إلقاء نظرة على الدروس المستفادة ، دعنا نلقي نظرة على كيفية تحويل تطبيق ويب أساسي مكتوب بلغة HTML و CSS وجافا سكريبت إلى تطبيق ويب تقدمي (PWA).

فيما يتعلق بإجمالي الوقت الذي يقضيه في إنشاء تطبيق الويب الصغير هذا ، سأضيف أنه من المحتمل أن يكون حوالي أسبوعين إلى ثلاثة أسابيع. ومع ذلك ، نظرًا لأنه تم القيام بذلك في أجزاء من 30 إلى 60 دقيقة في المساء ، فقد استغرق الأمر حوالي عام تقريبًا من أول التزام حتى قمت بتحميل ما أعتبره الإصدار "1.0" في أغسطس 2018. نظرًا لأنني حصلت على التطبيق " ميزة كاملة '، أو ببساطة التحدث ، في مرحلة كنت سعيدًا بها ، توقعت دفعة أخيرة كبيرة. كما ترى ، لم أفعل شيئًا من أجل تحويل التطبيق إلى تطبيق ويب تقدمي. اتضح أن هذا كان في الواقع أسهل جزء من العملية برمتها.

إنشاء تطبيق ويب تقدمي

والخبر السار هو أنه عندما يتعلق الأمر بتحويل تطبيق صغير مدعوم من JavaScript إلى "تطبيق ويب تقدمي" ، فهناك عدد كبير من الأدوات لتسهيل الحياة. إذا أعادت تفكيرك إلى الجزء الأول من هذه السلسلة ، فستتذكر أن كونك تطبيق ويب تقدميًا يعني تلبية مجموعة من المعايير.

للتعرف على كيفية قياس تطبيق الويب الخاص بك ، من المحتمل أن تكون محطتك الأولى هي أدوات Lighthouse في Google Chrome. يمكنك العثور على تدقيق تطبيق الويب التقدمي ضمن علامة التبويب "عمليات التدقيق".

هذا ما أخبرني به لايتهاوس عندما دخلت / خرجت لأول مرة من خلاله.

في البداية ، كان In / Out يحصل فقط على درجة ⁵⁵ ₁₀₀ لتطبيق الويب التقدمي. ومع ذلك ، فقد أخذتها من هناك إلى ¹⁰⁰ ₁₀₀ في أقل من ساعة!

لم تكن الملاءمة في تحسين تلك النتيجة ذات صلة بقدرتي. كان ذلك ببساطة لأن Lighthouse أخبرتني بالضبط ما يجب القيام به!

بعض الأمثلة على الخطوات المطلوبة: تضمين ملف manifest.json (بشكل أساسي ملف JSON يوفر بيانات وصفية حول التطبيق) ، وإضافة مجموعة كاملة من العلامات الوصفية في الرأس ، واستبدال الصور المضمنة في CSS للصور المرجعية لعناوين URL القياسية ، وإضافة مجموعة من صور الشاشة الرئيسية.

قد يبدو أن إنشاء عدد من صور الشاشة الرئيسية وإنشاء ملف بيان وإضافة مجموعة من العلامات الوصفية يتطلب الكثير في أقل من ساعة ولكن هناك تطبيقات ويب رائعة لمساعدتك في إنشاء تطبيقات الويب. كم هو جميل! لقد استخدمت https://app-manifest.firebaseapp.com. قم بتزويده ببعض البيانات حول تطبيقك وشعارك ، واضغط على إرسال وهو يزودك بملف مضغوط يحتوي على كل ما تحتاجه! من الآن فصاعدًا ، حان وقت النسخ واللصق فقط.

الأشياء التي كنت قد أجلتها لبعض الوقت بسبب نقص المعرفة ، مثل عامل الخدمة ، تمت إضافتها بسهولة إلى حد ما بفضل العديد من منشورات المدونة والمواقع المخصصة لموظفي الخدمة مثل https://serviceworke.rs. مع وجود عامل خدمة في مكانه ، فهذا يعني أن التطبيق يمكن أن يعمل دون اتصال بالإنترنت ، وهي ميزة ضرورية لتطبيق الويب التقدمي.

على الرغم من عدم ارتباطها بشكل صارم بجعل التطبيق PWA ، إلا أن علامة التبويب "التغطية" الخاصة بأدوات Chrome Dev Tools كانت مفيدة جدًا أيضًا. بعد الكثير من التكرار المتقطع على التصميم والكود على مدار أشهر ، كان من المفيد الحصول على إشارة واضحة إلى مكان وجود التعليمات البرمجية الزائدة عن الحاجة. لقد وجدت بعض الوظائف القديمة المتناثرة في قاعدة الشفرة التي نسيتها ببساطة!

باختصار ، بعد أن عملت من خلال توصيات تدقيق Lighthouse ، شعرت وكأنني حيوان أليف للمعلم:

الحقيقة هي أن أخذ التطبيق وجعله تطبيق ويب تقدميًا كان في الواقع أمرًا واضحًا بشكل لا يصدق.

مع الانتهاء من هذا الجزء الأخير من التطوير ، قمت بتحميل التطبيق الصغير إلى مجال فرعي من موقع الويب الخاص بي وكان هذا كل شيء.

بأثر رجعي

لقد مرت أشهر منذ إيقاف تطوير تطبيق الويب الصغير الخاص بي.

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

لذا ، فالحقيقة هي أنها بالكاد خدمة لا غنى عنها. كما أنها لا تضع أي عوائق للتطوير أو التصميم. لم أستطع إخبارك أنني سعيد بذلك أيضًا. لقد وصلت للتو إلى نقطة كنت سعيدًا بالتخلي عنها.

لكن لم يكن هذا هو الهدف من التمرين. أخذت الكثير من التجربة. ما يلي هو ما أعتبره أهم الوجبات السريعة.

التصميم هو تطوير

في البداية ، لم أكن أقدر التصميم بشكل كافٍ. لقد بدأت هذا المشروع معتقدًا أن وقتي في الرسم باستخدام لوحة وقلم أو في تطبيق Sketch ، كان الوقت الذي يمكن أن أمضيه بشكل أفضل مع الترميز. ومع ذلك ، اتضح أنني عندما انتقلت مباشرة إلى الكود ، كنت غالبًا مجرد أحمق مشغول. استكشاف المفاهيم أولاً بأدنى قدر ممكن من الدقة ، مما يوفر المزيد من الوقت على المدى الطويل.

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

رأيي الآن هو أن الورق والقلم الرصاص هما أفضل أدوات التخطيط والتصميم والترميز. تم حل كل مشكلة كبيرة بشكل أساسي بالورق وقلم الرصاص ؛ محرر النص مجرد وسيلة لتنفيذ الحل. بدون وجود شيء منطقي على الورق ، لا توجد فرصة للعمل في الكود.

الشيء التالي الذي تعلمت أن أقدره ، ولا أعرف لماذا استغرق الأمر وقتًا طويلاً لمعرفة ذلك ، هو أن التصميم تكراري. لقد اشتريت عن قصد في أسطورة مصمم برأس مال "D". شخص ما يتجول ، ممسكًا بقلمه الميكانيكي عند الحواف المستقيمة ، ويظهر غنائيًا حول الخطوط ويرشف على أبيض مسطح (مع حليب الصويا ، من الواضح) قبل الولادة العرضية التي شكلت الكمال البصري بالكامل في العالم.

هذا ، على عكس فكرة المبرمج "العبقري" ، هو أسطورة. إذا كنت جديدًا في التصميم ولكنك تجرب يدك ، أقترح ألا تتوقف عن الفكرة الأولى التي تثير حماستك. من الرخيص جدًا تجربة الاختلافات ، لذا احتضن هذا الاحتمال. لم يكن أي من الأشياء التي أحبها في تصميم In / Out موجودة في التصميمات الأولى.

أعتقد أن الروائي ، مايكل كريشتون ، هو من صاغ القول المأثور ، "الكتب ليست مكتوبة - إنها تُعاد كتابتها". تقبل أن كل عملية إبداعية هي نفسها في الأساس. اعلم أن الثقة في العملية تقلل من القلق والممارسة ستحسن من فهمك الجمالي وحكمك.

أنت المطور الآخر في مشروعك

لست متأكدًا مما إذا كان هذا خاصًا بالمشاريع التي لا يتم العمل عليها إلا بشكل متقطع ولكني قمت بالافتراض المتهور التالي:

"لست بحاجة إلى توثيق أي من هذا لأنه أنا وحدي ، ومن الواضح أنني سأفهمه لأنني كتبته."

لا شيء يمكن أن يكون أبعد عن الحقيقة!

كانت هناك أمسيات عندما اضطررت إلى العمل في المشروع لمدة 30 دقيقة ، لم أفعل شيئًا أكثر من محاولة فهم وظيفة كنت قد كتبتها قبل ستة أشهر. كانت الأسباب الرئيسية وراء استغراق إعادة توجيه الكود وقتًا طويلاً هي الافتقار إلى تعليقات الجودة والمتغيرات ذات الأسماء الرديئة والحجج الوظيفية.

أنا مجتهد جدًا في التعليق على التعليمات البرمجية في وظيفتي اليومية ، وأعي دائمًا أن شخصًا آخر قد يحتاج إلى فهم ما أكتبه. ومع ذلك ، في هذه الحالة ، كنت ذلك الشخص الآخر. هل تعتقد حقًا أنك ستتذكر كيف تعمل كتلة التعليمات البرمجية التي كتبتها في غضون ستة أشهر؟ لن تفعل. صدقني في هذا الأمر ، خذ بعض الوقت وعلق على هذا الشيء!

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

تصحيح

عندما تصطدم بالأخطاء وتكون قد كتبت كل التعليمات البرمجية ، فليس من العدل أن نقترح أن الخطأ من المحتمل أن يكون بين لوحة المفاتيح والكرسي. ومع ذلك ، قبل افتراض ذلك ، أقترح عليك اختبار حتى افتراضاتك الأساسية. على سبيل المثال ، أتذكر أنني استغرقت أكثر من ساعتين لإصلاح مشكلة افترضت أنها ترجع إلى الكود الخاص بي ؛ في نظام التشغيل iOS ، لم أتمكن من الحصول على مربع الإدخال الخاص بي لقبول إدخال النص. لا أتذكر لماذا لم يوقفني ذلك من قبل لكني أتذكر إحباطي من هذه المشكلة.

تبين أنه كان بسبب خطأ ، لم يتم إصلاحه بعد ، في Safari. تبين ذلك في Safari إذا كان لديك:

 * { user-select: none; }

في ورقة الأنماط الخاصة بك ، لن تأخذ مربعات الإدخال أي إدخال. يمكنك حل هذا باستخدام:

 * { user-select: none; } input[type] { user-select: text; }

وهو النهج الذي أتبعه في إعادة تعيين CSS "إعادة تعيين التطبيق". ومع ذلك ، فإن الجزء المحبط حقًا من هذا هو أنني تعلمت هذا بالفعل ومن ثم نسيته. عندما بدأت أخيرًا في التحقق من تتبع أخطاء WebKit أثناء تحري الخلل وإصلاحه ، وجدت أنني قد كتبت حلاً بديلاً في مؤشر ترابط تقرير الخطأ منذ أكثر من عام كامل مع الحد!

هل تريد البناء باستخدام البيانات؟ تعلم أساليب مصفوفة جافا سكريبت

ربما كان التقدم الأكبر الذي حققته مهاراتي في JavaScript من خلال خوض تمرين بناء التطبيق هذا هو التعرف على أساليب مصفوفة JavaScript. أنا الآن أستخدمها يوميًا لجميع احتياجات التكرار ومعالجة البيانات. لا يمكنني التأكيد بشكل كافٍ على مدى فائدة الطرق مثل map() ، و filter() ، و every() ، و findIndex() ، و find() ، reduce() . يمكنك حل أي مشكلة بيانات تقريبًا معهم. إذا لم يكن لديك بالفعل في ترسانتك ، ضع إشارة مرجعية على https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array الآن وحفر في أقرب وقت ممكن. تم هنا توثيق تداعي الخاص لأساليب المصفوفات المفضلة لدي.

قدم ES6 موفرات أخرى للوقت لمعالجة المصفوفات ، مثل Set و Rest و Spread . دللني بينما أشارك مثالاً واحدًا ؛ اعتاد أن يكون هناك حفنة من faff إذا كنت تريد إزالة التكرارات حتى من مصفوفة مسطحة بسيطة. ليس بعد الآن.

ضع في اعتبارك هذا المثال البسيط لمصفوفة مع الإدخال المكرر ، "السيد بينك":

 let myArray = [ "Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue", "Mr Pink" ];

للتخلص من التكرارات باستخدام ES6 JavaScript ، يمكنك الآن القيام بما يلي:

 let deDuped = [...new Set(myArray)]; // deDuped logs ["Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue"]

الشيء الذي كان يتطلب حلًا يدويًا أو الوصول إلى مكتبة أصبح الآن مخبوزًا في اللغة. باعتراف الجميع ، على مثل المصفوفة القصيرة التي قد لا تبدو مثل هذه الصفقة الكبيرة ولكن تخيل مقدار الوقت الذي يوفره عند النظر إلى المصفوفات التي تحتوي على مئات الإدخالات والتكرارات.

الصيانة والامن

أي شيء تقوم بإنشائه ويستفيد من NPM ، حتى لو كان فقط لأدوات البناء ، يحمل احتمال التعرض لمشاكل الأمان. يقوم GitHub بعمل جيد لإبقائك على دراية بالمشاكل المحتملة ولكن لا يزال هناك بعض عبء الصيانة.

بالنسبة لشيء ما هو مجرد مشروع جانبي ، يمكن أن يكون هذا قليلاً من الألم في الأشهر والسنوات التي تلي التطور النشط.

الحقيقة هي أنه في كل مرة تقوم فيها بتحديث التبعيات لإصلاح مشكلة أمنية ، فإنك تقدم إمكانية كسر بنيتك.

لأشهر ، بدت package.json بي. json هكذا:

 { "dependencies": { "gulp": "^3.9.1", "postcss": "^6.0.22", "postcss-assets": "^5.0.0" }, "name": "In Out", "version": "1.0.0", "description": "simple utility to see who's in and who's out", "main": "index.js", "author": "Ben Frain", "license": "MIT", "devDependencies": { "autoprefixer": "^8.5.1", "browser-sync": "^2.24.6", "cssnano": "^4.0.4", "del": "^3.0.0", "gulp-htmlmin": "^4.0.0", "gulp-postcss": "^7.0.1", "gulp-sourcemaps": "^2.6.4", "gulp-typescript": "^4.0.2", "gulp-uglify": "^3.0.1", "postcss-color-function": "^4.0.1", "postcss-import": "^11.1.0", "postcss-mixins": "^6.2.0", "postcss-nested": "^3.0.0", "postcss-simple-vars": "^4.1.0", "typescript": "^2.8.3" } }

وبحلول يونيو 2019 ، تلقيت هذه التحذيرات من GitHub:

لم يكن أي منها مرتبطًا بالمكونات الإضافية التي كنت أستخدمها بشكل مباشر ، فقد كانت جميعها تبعيات فرعية لأدوات البناء التي استخدمتها. هذا هو السيف ذو الحدين لحزم JavaScript. فيما يتعلق بالتطبيق نفسه ، لم تكن هناك مشكلة في In / Out ؛ التي لم تكن تستخدم أيًا من تبعيات المشروع. ولكن نظرًا لأن الكود كان موجودًا على GitHub ، فقد شعرت بوجوب واجب محاولة إصلاح الأمور.

من الممكن تحديث الحزم يدويًا ، مع بعض التغييرات الاختيارية على package.json. ومع ذلك ، فإن كل من Yarn و NPM لهما أوامر التحديث الخاصة بهما. لقد اخترت تشغيل yarn upgrade-interactive التي تمنحك وسيلة بسيطة لتحديث الأشياء من المحطة.

يبدو الأمر سهلاً بدرجة كافية ، حتى أن هناك مفتاحًا ملونًا صغيرًا يخبرك بالتحديثات الأكثر أهمية.

يمكنك إضافة - أحدث علامة --latest إلى أحدث إصدار رئيسي من التبعيات ، بدلاً من أحدث إصدار مصحح فقط. في بنس واحد ...

تكمن المشكلة في أن الأشياء تتحرك بسرعة في عالم حزمة JavaScript ، لذا فقد أدى تحديث بعض الحزم إلى أحدث إصدار ثم محاولة الإنشاء إلى ما يلي:

على هذا النحو ، --latest ملف package.json وحاولت مرة أخرى هذه المرة بدون العلامة الأخيرة. هذا حل مشكلاتي الأمنية. لم يكن الأمر الأكثر متعة لي في مساء يوم الاثنين على الرغم من أنني سأكون صادقًا.

هذا يمس جزءًا مهمًا من أي مشروع جانبي. أن تكون واقعيًا مع توقعاتك.

مشاريع جانبية

لا أعرف ما إذا كنتما متماثلان ولكني وجدت أن التفاؤل الدائر والإثارة يجعلانني أبدأ المشاريع وإذا حدث أي شيء ، فإن الإحراج والشعور بالذنب يجعلني أنهيها.

سيكون من الكذب أن أقول إن تجربة إنشاء هذا التطبيق الصغير في أوقات فراغي كانت مليئة بالمرح. كانت هناك مناسبات كنت أتمنى ألا أفتح فمي بشأنها لأي شخص. ولكن الآن تم الانتهاء منه ، فأنا مقتنع بنسبة 100٪ أنه كان يستحق الوقت المستثمر.

بعد قولي هذا ، من الممكن تخفيف الإحباط من مثل هذا المشروع الجانبي من خلال التحلي بالواقعية بشأن المدة التي سيستغرقها فهم المشكلات التي تواجهها وحلها. هل لديك 30 دقيقة فقط في الليلة ، وبضع ليالٍ في الأسبوع؟ لا يزال بإمكانك إكمال مشروع جانبي ؛ فقط لا تنزعج إذا كانت وتيرتك تبدو جليدية. إذا لم تستمتع الأشياء باهتمامك الكامل ، فاستعد بوتيرة أبطأ وأكثر ثباتًا مما كنت معتادًا عليه. هذا صحيح ، سواء كان ذلك في الترميز أو إكمال دورة تدريبية أو تعلم التوفيق أو كتابة سلسلة من المقالات حول سبب استغراق وقت طويل لكتابة تطبيق ويب صغير!

تحديد الهدف البسيط

لا تحتاج إلى عملية خيالية لتحديد الهدف. ولكن قد يساعد في تقسيم الأشياء إلى مهام صغيرة / قصيرة. أشياء بسيطة مثل "كتابة CSS للقائمة المنسدلة" يمكن تحقيقها بشكل مثالي في فترة زمنية محدودة. في حين أن "البحث وتنفيذ نمط تصميم لإدارة الدولة" ربما لا يكون كذلك. قسّم الأشياء. ثم ، تمامًا مثل Lego ، تتكامل القطع الصغيرة معًا.

بالتفكير في هذه العملية باعتبارها تقطيعًا بعيدًا في المشكلة الأكبر ، تذكرت اقتباس بيل جيتس الشهير:

"يبالغ معظم الناس في تقدير ما يمكنهم فعله في عام واحد ويقللون مما يمكنهم فعله في غضون عشر سنوات."

هذا من رجل يساعد في استئصال شلل الأطفال. يعرف بيل أغراضه. استمع إلى Bill y'all.

الشحن شيء أفضل من شحن لا شيء

قبل "شحن" تطبيق الويب هذا ، قمت بمراجعة الكود وشعرت بالإحباط الشديد.

على الرغم من أنني قد شرعت في هذه الرحلة من نقطة السذاجة الكاملة وانعدام الخبرة ، فقد اتخذت بعض الخيارات اللائقة عندما يتعلق الأمر بكيفية تصميم الكود (إذا كنت ستسامح هذا المصطلح). لقد بحثت ونفذت نمط تصميم واستمتعت بكل ما يقدمه هذا النمط. للأسف ، نظرًا لأنني أصبحت أكثر يأسًا لإنهاء المشروع ، فشلت في الحفاظ على الانضباط. الكود كما هو عبارة عن مزيج حقيقي من الأساليب ومليء بعدم الكفاءة.

في الأشهر التي تلت ، أدركت أن أوجه القصور هذه لا تهم حقًا. ليس صحيحا.

أنا معجب بهذا الاقتباس من Helmuth von Moltke.

"لا توجد خطة عمليات تمتد بشكل مؤكد إلى ما وراء الاتصال الأول بالقوة المعادية الرئيسية."

تمت إعادة صياغته على النحو التالي:

"لا توجد خطة تنجو من أول اتصال مع العدو".

ربما يمكننا أن نغليها أكثر ونذهب ببساطة مع "يحدث الهراء"؟

يمكنني أن أظن قدومي لتفاهم مع ما تم شحنه عبر القياس التالي.

إذا أعلن أحد الأصدقاء أنهم سيحاولون تشغيل الماراثون الأول لهم ، فسيكون تجاوزهم خط النهاية هو كل ما يهم - لن أكون موبخًا لهم في وقتهم النهائي.

لم أخطط لكتابة أفضل تطبيق ويب. كان الاختصاص الذي حددته لنفسي هو مجرد تصميم وإنشاء واحدة.

وبشكل أكثر تحديدًا ، من منظور التنمية ، أردت أن أتعلم أساسيات كيفية إنشاء تطبيق الويب. من وجهة نظر التصميم ، أردت أن أحاول حل بعض مشاكل التصميم (وإن كانت بسيطة) بنفسي. جعل هذا التطبيق الصغير يواجه تلك التحديات ثم بعضها. كان حجم JavaScript للتطبيق بأكمله 5 كيلوبايت فقط (مضغوط). حجم ملف صغير سأجد صعوبة في الوصول إليه مع أي إطار عمل. ربما باستثناء Svelte.

إذا كنت تضع لنفسك تحديًا من هذا النوع ، وتتوقع في وقت ما أن "تشحن" شيئًا ما ، فاكتب في البداية سبب قيامك بذلك. احتفظ بهذه الأسباب في مقدمة عقلك واسترشد بها. كل شيء هو في النهاية نوع من التسوية. لا تدع المُثُل السامية تشلّك من إنهاء ما خططت لفعله.

ملخص

بشكل عام ، مع مرور عام على عملي في In / Out ، تنقسم مشاعري بشكل عام إلى ثلاثة مجالات: الأشياء التي ندمت عليها ، والأشياء التي أرغب في تحسينها / إصلاحها والإمكانيات المستقبلية.

أشياء ندمت عليها

كما ألمحت إليه بالفعل ، شعرت بخيبة أمل لأنني لم ألتزم بما اعتبرته طريقة أكثر أناقة لتغيير حالة التطبيق وتقديمه إلى DOM. نمط المراقب ، كما تمت مناقشته في الجزء الثاني من هذه السلسلة ، والذي حل العديد من المشكلات بطريقة يمكن التنبؤ بها ، تم استبعاده في النهاية جانباً حيث أصبح "شحن" المشروع أولوية.

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

تحسين الداخل / الخارج

بعد اختيار الترميز الدلالي ، لم أقم بإتاحة إمكانية الوصول. عندما أنشأت In / Out كنت واثقًا من إمكانية الوصول إلى صفحة الويب القياسية ولكني لست على دراية كافية بمعالجة أحد التطبيقات. لقد قمت بمزيد من العمل / البحث في هذا المجال الآن ، لذلك سأستمتع بأخذ الوقت للقيام بعمل لائق لجعل هذا التطبيق أكثر سهولة.

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

كما أنني لم أضع أي اعتبار للشاشات الأكبر حجمًا. سيكون من المثير للاهتمام النظر في تحديات التصميم لجعله يعمل بأحجام أكبر ، بما يتجاوز مجرد جعله أنبوبًا للمحتوى.

الاحتمالات

نجح استخدام localStorage في تلبية احتياجاتي البسيطة ، لكن سيكون من الجيد أن يكون لديك مخزن بيانات "مناسب" لذلك لم يكن من الضروري القلق بشأن نسخ البيانات احتياطيًا. ستؤدي إضافة إمكانية تسجيل الدخول أيضًا إلى فتح إمكانية مشاركة تنظيم اللعبة مع شخص آخر. أو ربما يستطيع كل لاعب تحديد ما إذا كان يلعب بنفسه؟ إنه لأمر مدهش كم عدد السبل التي يمكنك استكشافها من هذه البدايات البسيطة والمتواضعة.

SwiftUI لتطوير تطبيقات iOS أمر مثير للاهتمام أيضًا. بالنسبة لشخص عمل مع لغات الويب فقط ، للوهلة الأولى ، يبدو SwiftUI وكأنه شيء أتشجع الآن على تجربته. من المحتمل أن أحاول إعادة بناء In / Out باستخدام SwiftUI - فقط للحصول على شيء محدد لبناء ومقارنة تجربة التطوير والنتائج.

وهكذا ، حان الوقت لإنهاء الأمور وإعطائك نسخة TL ؛ DR من كل هذا.

إذا كنت تريد معرفة كيفية عمل شيء ما على الويب ، أقترح تخطي الأفكار المجردة. تخلص من الأطر ، سواء كانت CSS أو JavaScript حتى تفهم حقًا ما هي عليه.

التصميم متكرر ، احتضن هذه العملية.

قم بحل المشاكل في أدنى وسط دقة تحت تصرفك. لا تذهب إلى الكود إذا كان بإمكانك اختبار الفكرة في Sketch. لا ترسمه في Sketch إذا كان بإمكانك استخدام القلم والورق. اكتب المنطق أولا. ثم اكتبها في الكود.

كن واقعيًا ولكن لا يأس أبدًا. يمكن أن يؤدي تطوير عادة تقطيع شيء ما لمدة 30 دقيقة في اليوم إلى نتائج. هذه الحقيقة صحيحة مهما كان الشكل الذي تتخذه مهمتك.