Promise

عند تنفيذ الشيفرة المقدمة، يتم إنشاء Promise بواسطة الدالة الرئيسية للـ Promise التي تأخذ وظيفتين كمعاملين: resolve و reject. في هذه الحالة، تم استخدام setTimeout لتأخير وظيفة الـ reject بمقدار 1000 ميلي ثانية، مما يؤدي إلى رفض الـ Promise بعد مرور هذه الفترة.

عندما يتم استدعاء الـ Promise، يتم تسجيل وظيفة الـ catch للتعامل مع الرفض الذي قد يحدث، ومن ثم وظيفة الـ then للتعامل مع النجاح في حال حدوثه.

الآن، بما أن وظيفة الـ reject قد تم استدعاؤها بعد مرور 1000 ميلي ثانية، فإن وظيفة الـ catch ستتم استدعاؤها أولاً، حيث تقوم بتسجيل “rejected” في السجل. وبعد ذلك، وظيفة الـ then تأتي لتُنفذ، وتقوم بتسجيل “success” في السجل.

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

بالتأكيد، دعنا نوسع قليلاً في شرح كيفية عمل وظائف الـ then والـ catch في Promise.

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

في حالة حدوث نجاح للوعد، يتم استدعاء الوظيفة المرفوعة إلى then، حيث يتم تمرير القيمة التي تم حل الوعد إليها كمعامل. بمعنى آخر، يحدث هذا عندما يتم استدعاء resolve.

أما إذا حدث فشل (رفض) الوعد، سيتم استدعاء الوظيفة المرفوعة إلى catch، حيث يمرر لها قيمة السبب الذي تم رفض الوعد بسببه. يمكننا أن نفكر في هذا السيناريو عند استدعاء reject.

لذلك، عند استخدام وظائف then و catch معًا كما هو الحال في الشيفرة المقدمة، فإن كل منهما يُعتبر جزءًا من سلسلة من الإجراءات التي يجب اتخاذها عند حدوث الوعد. سيتم تنفيذ الوظيفة المرتبطة ب catch عند حدوث فشل الوعد، وسيتم تنفيذ الوظيفة المرتبطة ب then عند حدوث نجاح الوعد. وهذا هو السبب في أننا نرى النتيجة المطلوبة التي تظهر كلاً من “rejected” و “success” في السجل.

هذا النمط من التعامل مع الوعود يجعل من السهل كتابة الشيفرة التي تتعامل بشكل فعّال مع العمليات غير المتزامنة والتحكم في تسلسل الإجراءات بناءً على نتائج العمليات المتزامنة.

في الشيفرة المُقدمة، يتم استخدام مفهومين مهمين في JavaScript: الوعود (Promises) والدوال. يستخدم الكود الوعود لإدارة التنفيذ الغير متزامن (Asynchronous)، ويُظهر كيف يمكن استخدام الدوال لتحكم في تدفق البيانات.

أولاً، يُعرف في الكود دالة getY(x) التي تقوم بإرجاع وعد (Promise). هذه الوعدة تحتوي على دالة تأخير (setTimeout) التي تنتظر 100 ميلي ثانية قبل أن تستدعي دالة الحل (resolve) وتقوم بتمرير القيمة (3 * x) – 1 إليها.

ثانيًا، تعرف دالة foo(bar, baz)، حيث يتم فيها حساب قيمة x التي تمثل حاصل ضرب bar و baz، ومن ثم يُرجع مصفوفة من وعود. الوعد الأول يُحل بقيمة x، بينما الوعد الثاني يُحل بنتيجة دالة getY(x).

ثالثاً، تعرف دالة spread(fn) التي تعيد دالة جديدة مرتبطة بالوسيط (bound) تستدعي fn وتمرر لها الوسيط null. هذا يعني أنه عند استدعاء الدالة المُعادة من spread، سيتم تمرير الوسيط null كالمُعد للدالة المُنطوية fn.

أخيرًا، تستخدم Promise.all() لتنفيذ جميع الوعود الموجودة في مصفوفة الوعود التي تم إرجاعها من foo(10, 20)، وبعد حلها بنجاح، يتم استدعاء دالة spread() مع دالة callback التي تقوم بطباعة قيمتي x و y المحلولة من الوعود.

بشكل مبسط، عندما يتم استدعاء spread() مع دالة callback المحددة، يُنشئ المُنظر Function.apply.bind دالة جديدة مرتبطة بالوسيط تنفذ الدالة callback المعطاة لها، وتقوم بتمرير الوسيط null للدالة callback، مما يتيح للدالة callback الوصول إلى قيم x و y المحسوبة بشكل صحيح من الوعود المُستوفاة.

بالطبع، دعنا نواصل تحليل وشرح الشيفرة بمزيد من التفاصيل.

عندما يُستدعى spread() ويُمرر إليها الدالة callback التي تستقبل x و y، يتم إنشاء نظر (wrapper) جديد لهذه الدالة باستخدام Function.apply.bind. لكي نفهم كيف يحدث ذلك، دعنا نقوم بتفكيك هذه العملية:

• Function.apply هي دالة في JavaScript تُستخدم لتنفيذ دالة مع وسيط معين ومصفوفة من الوسائط كمعطيات. يتم تحديد الدالة المراد تنفيذها باستخدام this الذي يتم تمريره لـ apply.

• bind هو طريقة تُستخدم لربط قيمة معينة بـ this في دالة محددة، مما يؤدي إلى إنشاء نظر جديد للدالة مع this الجديد.

بالتالي، باستخدام Function.apply.bind، نقوم بربط null كقيمة this مع Function.apply، مما يعني أنه عند استدعاء الدالة المنشأة، فإن this سيكون null. ومن ثم، عندما تُستدعى الدالة المُنشأة مع وسيطين (الدالة callback و null)، يُقوم apply بتنفيذ الدالة callback وتمرير null كقيمة this.

بهذه الطريقة، عندما تحل الوعود في Promise.all()، يتم استدعاء الدالة المنشأة من spread()، والتي تقوم بتنفيذ الدالة callback التي تم تمريرها لها، وتمرير null كقيمة this. ونظرًا لأن الدالة callback مربوطة مع null باستخدام Function.apply.bind، فإنها تتمكن من الوصول إلى الوسيطين x و y بشكل صحيح.

لذا، في النهاية، عندما يُستدعى spread()، يُنشئ ويُقيِّد نظرٌ جديد للدالة callback، والتي بدورها تستقبل x و y، وهذا يسمح لنا بالوصول إلى قيم x و y التي تم حسابها من الوعود المُستوفاة بنجاح.

عند النظر إلى الشيفرة المقدمة، يبدو أن المشكلة تكمن في التسلسل الزمني لاسترجاع البيانات من خدمة المستخدمين (UserService). عندما يتم استدعاء الدالة getUser في UserService، يتم إرجاع البيانات كوعد (Promise). ومع ذلك، يتم استخدام هذا الوعد في UserPageComponent دون انتظار حتى يتم حله بالشكل المناسب. في الواقع، الوعد يتم تنفيذه بشكل غير متزامن، وقبل أن يتم حله بالقيمة المتوقعة.

عندما يتم استدعاء this.userService.getUser(id) في ngOnInit من UserPageComponent، يبدأ الطلب للحصول على بيانات المستخدم بشكل فوري. ولكن في الوقت نفسه، المتغير this.user لم يتم تعريفه بعد، لذلك عند محاولة الوصول إلى user.id، يتم إرجاع الخطأ “Cannot read property ‘id’ of undefined” لأن القيمة user ليست معروفة بعد.

لحل هذه المشكلة، يمكن استخدام بنية الوعد بشكل صحيح. بدلاً من استخدام .then() للتعامل مع الوعد، يمكن استخدام مفهوم async و await لضمان اكتمال الوعد قبل محاولة الوصول إلى البيانات. وفي هذه الحالة، يتم تحويل ngOnInit إلى دالة ذات تعليمات برمجية متزامنة باستخدام async و await.

الشيفرة المعدلة ستكون على النحو التالي:

typescriptCopy code
async ngOnInit(): Promise<void> {
    this.route.params.forEach(async (params: Params) => {
        let id = +params['id'];
        try {
            let user = await this.userService.getUser(id);
            console.log(user.id);
            this.user = user;
        } catch (error) {
            console.error("Error fetching user:", error);
        }
    });
}

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

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

عند النظر إلى الشيفرة المقدمة، يبدو أن المشكلة تكمن في التسلسل الزمني لاسترجاع البيانات من خدمة المستخدمين (UserService). عندما يتم استدعاء الدالة getUser في UserService، يتم إرجاع البيانات كوعد (Promise). ومع ذلك، يتم استخدام هذا الوعد في UserPageComponent دون انتظار حتى يتم حله بالشكل المناسب. في الواقع، الوعد يتم تنفيذه بشكل غير متزامن، وقبل أن يتم حله بالقيمة المتوقعة.

عندما يتم استدعاء this.userService.getUser(id) في ngOnInit من UserPageComponent، يبدأ الطلب للحصول على بيانات المستخدم بشكل فوري. ولكن في الوقت نفسه، المتغير this.user لم يتم تعريفه بعد، لذلك عند محاولة الوصول إلى user.id، يتم إرجاع الخطأ “Cannot read property ‘id’ of undefined” لأن القيمة user ليست معروفة بعد.

لحل هذه المشكلة، يمكن استخدام بنية الوعد بشكل صحيح. بدلاً من استخدام .then() للتعامل مع الوعد، يمكن استخدام مفهوم async و await لضمان اكتمال الوعد قبل محاولة الوصول إلى البيانات. وفي هذه الحالة، يتم تحويل ngOnInit إلى دالة ذات تعليمات برمجية متزامنة باستخدام async و await.

الشيفرة المعدلة ستكون على النحو التالي:

typescriptCopy code
async ngOnInit(): Promise<void> {
    this.route.params.forEach(async (params: Params) => {
        let id = +params['id'];
        try {
            let user = await this.userService.getUser(id);
            console.log(user.id);
            this.user = user;
        } catch (error) {
            console.error("Error fetching user:", error);
        }
    });
}

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

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

عند استخدام واجهة برمجة التطبيقات (API) Fetch في JavaScript، فإنه يعود بشكل طبيعي بنتيجة الطلب في شكل “Promise”، وهو نمط متزايد في JavaScript يُستخدم للتعامل مع عمليات غير متزامنة مثل استرداد البيانات من الشبكة. عند استخدام دالة fetch()، يتم إرجاع Promise يحتوي على كائن Response.

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

عندما تقوم بتحديد .then() بعد response.json()، فإنك تقول للمتصفح “عندما يكون الJSON جاهزًا، فقم بتشغيل الكود داخل هذا الـcallback”. وهكذا، عندما يتم استرجاع البيانات بنجاح، يتم تشغيل الكود داخل .then() وتتوفر البيانات JSON.

لذلك، السبب في عدم توفر البيانات JSON مباشرة داخل console.log(json) في المثال الأول هو أن البيانات لم تكتمل استرجاعها عند تشغيل الكود. وبالتالي، يجب الانتظار حتى تكتمل العملية، ويتم ذلك من خلال استخدام .then() كما في المثال الثاني.

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

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

لذا، عند استخدام واجهة برمجة التطبيقات Fetch في JavaScript، يجب أن تتوقع أن تعود العديد من الوظائف بـ Promise، بما في ذلك fetch() نفسها ودوال التحويل مثل response.json()، وهذا يُعد جزءًا من طبيعة التعامل مع العمليات غير المتزامنة في JavaScript.

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

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

عندما تقوم بتنفيذ الشفرة التي قدمتها، فإن النتيجة المتوقعة هي أن تظهر “promise resolve” في الكونسول قبل “setTimeout” في كل مرة. السبب وراء ذلك يعود إلى كيفية عمل كل من setTimeout و Promise في JavaScript وكيفية تنظيم الحلقة الرئيسية (event loop).

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

أما بالنسبة لـ Promise، فإن استدعاء Promise.resolve(1).then() يضيف مهمة إلى طابور المهام الذي سيتم تنفيذه في الحلقة القادمة من الحلقة الرئيسية. وبما أن هذه المهمة تنتظر استجابة من الـ Promise قبل تنفيذها، فإنها تحظى بالأولوية على setTimeout التي ليست لديها اعتماد على أي Promise وتنتظر فقط اكتمال الفترة الزمنية المحددة.

بالتالي، تتم تنفيذ “promise resolve” دائمًا قبل “setTimeout” في هذا السياق. وهذا يعكس طريقة عمل الحلقة الرئيسية في JavaScript وكيفية تنظيم تنفيذ المهام فيها استنادًا إلى نوع المهمة واعتمادها على Promise أو عدمه.

بالتأكيد، دعني أوسع شرحي لتوضيح كيفية عمل setTimeout و Promise بشكل أكبر والتأثيرات التي قد تكون لها على ترتيب تنفيذ الأوامر في JavaScript.

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

أما بالنسبة للـ Promise، فهو آلية لإدارة العمليات القائمة على الوقت والتي قد تكون غير متزامنة، مثل استرداد البيانات من قاعدة البيانات أو استجابة لطلبات الشبكة. عند استدعاء Promise.resolve(1).then()، يتم إنشاء Promise وحلها بقيمة معينة (هنا الرقم 1)، ويتم تنفيذ الوظيفة الممررة إلى then عندما يتم حل الـ Promise.

الآن، بالنظر إلى تفسير السياق الذي قدمته، فإن “promise resolve” دائمًا تظهر قبل “setTimeout” بسبب تفضيلية تنفيذ Promise على setTimeout في الحلقة الرئيسية. هذا يحدث لأن Promise يتمتع بالقدرة على تجميع الأعمال المستقبلية التي يجب تنفيذها، في حين يُنظر إلى setTimeout كوظيفة مستقلة للتأجيل.

بالإضافة إلى ذلك، يمكن للمهام المؤجلة التي تعتمد على Promise أن تتعلق بأنواع معينة من العمليات، مثل استجابة طلب شبكة أو استرداد بيانات من قاعدة بيانات، مما يعطيها أولوية أعلى في التنفيذ على مهام setTimeout التي قد تكون تأثيرها أقل ملموسًا على سير البرنامج.

باختصار، فإن الفرق الرئيسي في ترتيب تنفيذ “promise resolve” قبل “setTimeout” يعود إلى طبيعة الوظائف وكيفية تفضيل وتنظيم تنفيذها في الحلقة الرئيسية، حيث يعتمد Promise على نمط أكثر تطورًا وتنظيمًا للتنفيذ بالمقارنة مع setTimeout الذي يعتبر أكثر تباينًا واستقلالية.

لفهم كيفية الانتظار حتى ينتهي تدفق البيانات (stream) في Node.js، يمكنك استخدام ميزة التحكم بالتدفق (stream control) التي توفرها مكتبة Node.js. في حالتك، تحتاج إلى ضمان أن عمليتي الكتابة إلى الملف واستخراج النص من الملف تكتملان قبل المتابعة إلى الدورة القادمة من حلقة الـ for. يمكن القيام بذلك عن طريق استخدام مكتبة async في Node.js، التي توفر وظيفة eachSeries التي تنفذ الوعود بترتيب متسلسل.

اليك كيفية تعديل الكود لينتظر حتى ينتهي تدفق البيانات ويتم استخراج النص قبل المتابعة:

javascriptCopy code
let promises = [];
promises.push(promise1);
promises.push(promise2);
promises.push(promise3);

Promise.all(promises).then((responses) => {
  async.eachSeries(responses, (response, callback) => {
    if (response.property === something) {
      //do something
      callback(); // تستمر إلى الوعد التالي مباشرة
    } else {
      let file = fs.createWriteStream('./hello.pdf');
      let stream = response.pipe(file);
      stream.on('finish', () => {
        extract(filePath, {splitPages: false}, (err, text) => {
          if (err) {
            console.log(err);
          } else {
            arrayOfDocuments[i].text_contents = text;
            callback(); // تستمر إلى الوعد التالي بعد استخراج النص من الملف
          }
        });
      });
    }
  }, () => {
    // عندما تنتهي من استخراج النصوص من جميع الملفات
    // يمكنك القيام بأي شيء آخر هنا بعد اكتمال جميع الوعود
  });
});

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

، (callback) => {
if (response.property === something) {
//do something
callback(); // تابع للانتقال إلى التالي
} else {
let file = fs.createWriteStream(‘./hello.pdf’);
let stream = response.pipe(file);

scssCopy code
  stream.on('finish', () => {
    extract(filePath, {splitPages: false}, (err, text) => {
      if (err) {
        console.log(err);
        callback(err); // تابع مع خطأ إذا حدث
      } else {
        // تخزين النص في مصفوفة الوثائق
        arrayOfDocuments[i].text_contents = text;
        callback(); // انتهى بنجاح، يمكن المتابعة إلى التالي
      }
    });
  });
}

}, (err) => {
if (err) {
console.log(err);
} else {
// تمت المعالجة بنجاح
}
});
});

goCopy code

تم استخدام دالة `eachSeries` لتنفيذ الوعود بشكل متسلسل، مما يضمن أن عمليات الكتابة إلى الملف واستخراج النص تنتهيان قبل المتابعة إلى التدفق القادم.

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

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

تبني JavaScript العديد من الأساليب لتحقيق هذا الهدف. فيما يلي نظرة على بعض أنماط التصميم المتعلقة بالوحدات في JavaScript:

1. النمط الكائني (Object-Oriented):

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

2. نمط الوسائط والمرسلين (Publish/Subscribe):

يعتمد على إشارات واشتراكات للتفاعل بين الوحدات. هذا يُمكّن الوحدات المختلفة من التواصل بدون ارتباط مباشر.

3. الوحدات القابلة لإعادة الاستخدام (Revealing Module Pattern):

يقوم بتعريف وحدة ويكشف عن جزء من الواجهة العامة. يُسهم في تحقيق الكتابة النظيفة والشيفرة الصيانية.

4. نمط التصميم المستند إلى الخدمات (Service-Oriented Design):

يركز على تقديم الوحدات كخدمات مستقلة. يعزز إعادة الاستخدام والتبادلية بين الوحدات.

5. نمط الوسيط (Mediator Pattern):

يستخدم كائنًا وسيطًا للتنسيق بين الوحدات المختلفة، مما يقلل من التباعد الزمني والتأثير المتبادل.

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

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

6. نمط الـ MVC (Model-View-Controller):

يُقسم التطبيق إلى ثلاثة أقسام رئيسية: النموذج (Model) الذي يدير البيانات والمنطق، والعرض (View) الذي يعرض البيانات للمستخدم، والتحكم (Controller) الذي يدير التفاعل بين النموذج والعرض. هذا يساهم في فصل المسؤوليات وتحقيق تنظيم أفضل.

7. نمط Flux:

تم تطويره بواسطة Facebook لإدارة حالة التطبيق بشكل فعال. يستخدم نمط الـ Flux تدفق البيانات في اتجاه واحد، مما يساعد في تنظيم التفاعلات وتجنب تشابك البيانات.

8. نمط Dependency Injection:

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

9. نمط الـ Promise:

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

10. نمط الـ Decorator:

يتيح للمطورين إضافة سلوك إضافي للوحدات بشكل ديناميكي. يُسهم في توسيع وظائف الوحدات بدون تعديل الشيفرة الأساسية.

11. نمط الـ Web Components:

يسعى إلى تجميع العناصر والوحدات بشكل قابل للفصل. يمكن للمطورين إنشاء عناصر ويب مستقلة تعتمد على معايير الويب.

12. نمط الـ Reactive Programming:

يركز على التفاعل بين الوحدات بطريقة فعّالة. يسمح بالتعامل مع التغييرات في البيانات بشكل سلس وتلقائي.

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