لماذا هو مضاد للنمط؟

مرحبا. في سبتمبر ، ستبدأ العديد من الدورات التدريبية حول تطوير JS في OTUS في وقت واحد ، وهي: JavaScript Developer. محترف ، مطور جافا سكريبت. مطور أساسي و React.js. استعدادًا لبدء هذه الدورات ، قمنا بإعداد ترجمة أخرى مثيرة للاهتمام من أجلك ، ونعرض أيضًا الاشتراك في دروس تجريبية مجانية حول الموضوعات التالية:

• تطوير مكتبة المكونات على React + Storybook
• اختبار التنمية المدفوعة في JS أو كيفية بدء البرمجة المحبة
• ترحيل مشروع حقيقي من Javascript إلى Typescript - الآلام والميزات

الآن دعنا ننتقل إلى المقال.

---

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



كيف يصل أحد المكونات إلى المعلومات (خاصة متغير الحالة) الموجودة في مكون آخر؟ كيف يستدعي أحد المكونات دالة موجودة في مكون آخر؟



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



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



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

النهج القياسي: استخدم الدعائم لتمرير القيم

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



معظم التطبيقات ذات طبقات. في التطبيقات المعقدة ، يمكن أن تتداخل الهياكل بعمق شديد. قد تبدو البنية العامة على النحو التالي:



App→ يشير إلى → ContentArea

ContentArea→ يشير إلى → MainContentArea

MainContentArea→ يشير إلى → MyDashboard

MyDashboard→ يشير إلى → MyOpenTickets

MyOpenTickets→ يشير إلى TicketTable

TicketTableتسلسل → TicketRow

الكل TicketRow→ يشير إلى →TicketDetail



من الناحية النظرية ، يمكن لف هذا الطوق لفترة طويلة. جميع المكونات هي جزء من الكل. بتعبير أدق ، جزء من التسلسل الهرمي. ولكن هنا السؤال الذي يطرح نفسه:



هل يمكن للمكون TicketDetailفي المثال أعلاه قراءة قيم الحالة المخزنة فيها ContentArea؟ أو. يمكن للمكون TicketDetailاستدعاء الوظائف الموجودة في ContentArea؟

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



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



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



ContentArea→ MainContentArea→ MyDashboard→ MyOpenTickets→ TicketTable→ TicketRow→ TicketDetail



أي لتمرير متغير الحالة من ContentAreaإلى TicketDetail، نحتاج إلى القيام بالكثير من العمل. يدرك المطورون المتمرسون أن هناك سلسلة طويلة قبيحة من تمرير القيم والوظائف في شكل دعائم عبر مستويات وسيطة من المكونات. الحل مرهق للغاية لدرجة أنني تخليت عن تعلم React عدة مرات بسببه.

الوحش المسمى Redux

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



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



لذلك جاءوا مع Redux.

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



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



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



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

التفاعل مع القيم المشتركة في React

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

كما قلت من قبل ، إذا كنت لا تستطيع الاستغناء عن أداة إدارة حالة منفصلة ، فإن MobX أفضل بنحو مليون مرة من Redux! ولكن أنا تعذبها على السؤال أكثر خطورة. إنها تلامس العقل الجماعي لمطوري React:



لماذا نستولي دائمًا على أداة إدارة الدولة أولاً؟



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



تخيل أنه في التطبيق الافتراضي الذي كتبته أعلاه ، قمنا بإنشاء ملف مثل هذا:

// components.js
let components = {};
export default components;

و هذا كل شيء. فقط سطرين قصيرين من التعليمات البرمجية. نقوم بإنشاء كائن فارغ - كائن JS قديم جيد . نقوم بتصديره بشكل افتراضي مع export default.



الآن دعنا نرى كيف يمكن أن تبدو الكود داخل المكون <ContentArea>:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      components.ContentArea = this;
   }

   consoleLog(value) {
      console.log(value);
   }

   render() {
      return <MainContentArea/>;
   }
}

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



في البداية ، قمنا باستيراد كائن بسيط components. ثم أضفنا خاصية جديدة إلى الكائن في المُنشئ componentsباسم مكون React الحالي ( this) ، ونشير في هذه الخاصية إلى المكون this. الآن ، في كل مرة نصل فيها إلى كائن المكونات ، سيكون لدينا وصول مباشر إلى المكون <ContentArea>.



دعونا نرى ما يحدث في أسفل التسلسل الهرمي. <TicketDetail>يمكن أن يكون المكون مثل هذا:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      components.ContentArea.consoleLog('it works');
      return <div>Here are the ticket details.</div>;
   }
}

إليكم ما يحدث. في كل مرة TicketDetailيتم فيها تقديم consoleLog()المكون ، سيتم استدعاء الوظيفة المخزنة في المكون ContentArea.



لاحظ أن الوظيفة consoleLog()لا يتم تمريرها عبر التسلسل الهرمي بأكمله من خلال الخاصيات. في الواقع ، consoleLog()لا يتم تمرير الوظيفة في أي مكان - وليس في أي مكان - إلى أي مكون.



ومع ذلك TicketDetailيمكنها استدعاء الوظيفة consoleLog()المخزنة فيها ContentArea، لأننا فعلنا شيئين:

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

هذا النهج لا يعمل فقط مع الدوال / الاسترجاعات. يمكن استخدامه للاستعلام المباشر عن قيم متغيرات الحالة. دعنا نتخيل ما <ContentArea>يشبه هذا:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   render() {
      return <MainContentArea/>;
   }
}

ثم نكتب <TicketDetail>مثل هذا:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return <div>Here are the ticket details.</div>;
   }
}

الآن ، في كل مرة يتم فيها تقديم المكون <TicketDetail، سيبحث عن قيمة المتغير state.reduxSucksفي <ContentArea>. إذا أرجع المتغير قيمة true، console.log()فستقوم الوظيفة بطباعة رسالة إلى وحدة التحكم. سيحدث هذا حتى إذا ContentArea.state.reduxSucksلم يتم تمرير قيمة المتغير إلى أسفل الشجرة مطلقًا - إلى أي من المكونات - عبر props. لذلك ، باستخدام كائن JS أساسي واحد بسيط يعيش خارج دورة حياة React القياسية ، يمكننا جعله بحيث يمكن لأي تابع قراءة متغيرات الحالة مباشرة من أي أصل تم تحميله في كائن المكونات. يمكننا حتى استدعاء وظائف المكون الرئيسي في سلالته.



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



أولاً ، في المكون ، <ContentArea>سننشئ دالة بسيطة تغير قيمة المتغير reduxSucks.

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
   }

   render() {
      return <MainContentArea/>;
   }
}

بعد ذلك ، في المكون ، <TicketDetail>سنسمي هذه الطريقة من خلال الكائن components:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

الآن ، بعد كل تصيير لمكون ، <TicketDetail>سيكون المستخدم قادرًا على الضغط على زر يغير (تبديل) قيمة المتغير ContentArea.state.reduxSucksفي الوقت الفعلي ، حتى لو ContentArea.toggleReduxSucks()لم يتم تمرير الوظيفة مطلقًا إلى أسفل الشجرة من خلال الدعائم.



مع هذا النهج ، يمكن للمكون الأصل استدعاء الوظيفة مباشرة من التابع لها. هيريس كيفية القيام بذلك. <ContentArea>سيبدو المكون المحدث كما يلي:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
      components.TicketTable.incrementReduxSucksHasBeenToggledXTimes();
   }

   render() {
      return <MainContentArea/>;
   }
}

الآن دعنا نضيف المنطق إلى المكون <TicketTable>. مثله:

// ticket.table.js
import components from './components';
import React from 'react';
import TicketRow from './ticket.row';

export default class TicketTable extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucksHasBeenToggledXTimes: 0 };
      components.TicketTable = this;
   }

   incrementReduxSucksHasBeenToggledXTimes() {
      this.setState((previousState, props) => {
         return { reduxSucksHasBeenToggledXTimes: previousState.reduxSucksHasBeenToggledXTimes + 1};
      });      
   }

   render() {
      const {reduxSucksHasBeenToggledXTimes} = this.state;
      return (
         <>
            <div>The `reduxSucks` value has been toggled {reduxSucksHasBeenToggledXTimes} times</div>
            <TicketRow data={dataForTicket1}/>
            <TicketRow data={dataForTicket2}/>
            <TicketRow data={dataForTicket3}/>
         </>
      );
   }
}

نتيجة لذلك ، <TicketDetail>لم يتغير المكون . لا يزال يبدو مثل هذا:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

هل لاحظت الشذوذ المرتبط بهذه الفئات الثلاثة؟ في التسلسل الهرمي لتطبيقنا ContentArea، هذا هو المكون الرئيسي لـ TicketTable، وهو المكون الرئيسي لـ TicketDetail. هذا يعني أنه عندما نقوم بتركيب أحد المكونات ContentArea، فإنه لا "يعرف" بعد عن وجوده TicketTable، والدالة toggleReduxSucks()المكتوبة فيها ContentAreaتستدعي ضمنيًا وظيفة الطفل :.

incrementReduxSucksHasBeenToggledXTimes()اتضح أن الكود لن يعمل ، أليس كذلك؟



لكن لا.



نظرة. لقد أنشأنا عدة مستويات في التطبيق ، وهناك طريقة واحدة فقط لاستدعاء الوظيفة toggleReduxSucks(). مثله.

1. نصعد ونقدم ContentArea.
2. أثناء هذه العملية ، يتم تحميل مرجع للمكونات في كائن المكونات ContentArea.
3. يتم تثبيت النتيجة وتقديمها TicketTable.
4. أثناء هذه العملية ، يتم تحميل مرجع للمكونات في كائن المكونات TicketTable.
5. يتم تثبيت النتيجة وتقديمها TicketDetail.
6. « reduxSucks» (Toggle reduxSucks).
7. « reduxSucks».
8. toggleReduxSucks(), ContentArea.
9. incrementReduxSucksHasBeenToggledXTimes() TicketTable .
10. , , « reduxSucks», TicketTable components. toggleReduxSucks() ContentArea incrementReduxSucksHasBeenToggledXTimes(), TicketTable, components.

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

أدوات إدارة الثروات - تفريغ

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

المعروفة "المشاكل" مع هذا النهج

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

• يعمل بشكل أفضل مع الفردي .
  
  
  
  على سبيل المثال ، في التسلسل الهرمي لدينا ، يحتوي المكون <TicketTable> على مكونات <TicketRow> بعلاقة من صفر إلى كثير. إذا كنت تريد تخزين المرجع لكل مكون محتمل داخل مكونات <TicketRow> (ومكوناتها الفرعية <TicketDetail>) في ذاكرة التخزين المؤقت للمكونات ، فيجب عليك تخزينها في مصفوفة ، وقد يصبح هذا الأمر صعبًا. لطالما تجنبت هذا.
• components , / , components. .
  
  , . , , . / , , components.
• , components, ( setState()), setState(), .

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



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



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



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

فلماذا هذا الأسلوب مزعج جدًا لمطوري React؟

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

• , .
  
  
  
  .... , , Redux ( MobX, ) / React-. , . — . , /, . : , components. , / components, / , components. /, components , components . , , . , , Redux, MobX, - .
• React « ». … .
  
  
  
  … . ? , . — - « » « », , , . React, . , . . « », . , React 100 %, ( ) , .

, ?

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



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



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

دروس مجانية:

• تطوير مكتبة المكونات على React + Storybook
• اختبار التنمية المدفوعة في JS أو كيفية بدء البرمجة المحبة
• ترحيل مشروع حقيقي من Javascript إلى Typescript - الآلام والميزات