ما هي حياة المبدعين للمكتبات الشعبية مفتوحة المصدر؟ بالطبع ، من الجيد أن تساعد نتيجة عملك الكثير من الناس حول العالم. ولكن هل تجد نفسك غارقًا في المهام التي ليست حتى وظيفتك الرئيسية؟ كيف تتعامل معها؟ ما مدى جرأة تفويض السلطة؟
يدرك
ميشيل ويستسترات جيدًا كل هذا:
تحتوي مكتبة
MobX الخاصة به على أكثر من 17000 نجمة على github ، وقد تجاوز عدد المساهمين فيها مائة. وسرعان ما سيأتي ميشيل إلى روسيا للتحدث في HolyJS ، لذلك سأله الرجال من لجنة البرنامج في المؤتمر (ديمتري ديمتري
ماخنيف وماغنيف
وإيفجيني بونوبوس كوت) بالتفصيل: عن المصدر المفتوح بشكل عام ، وتحديداً عن MobX ، وعن المؤتمرات.
يوجين: هل يمكنك أن تخبر عن نفسك لأول مرة لأولئك الذين لا يعرفونك؟"نعم بالطبع." اسمي ميشيل ويستستراتي (وهو أمر يصعب على معظم الناس نطقه) ، أنا من هولندا. في أغلب الأحيان يعرفونني من عملي على MobX أو على الغطس. أنا أعمل لدى Mendix. نصنع برمجيات تصنع البرمجيات: منصة تطوير التطبيقات التي تستخدمها العديد من الشركات الاستشارية. نقوم بأتمتة عدد كبير من شركات التأمين المصرفي والأنظمة المماثلة. أقوم بالجانب التقني - وهذا ما يعجبني. وقبل حوالي عامين ، انخرطت في عالم المصدر المفتوح ، منذ تلك اللحظة كنت نشيطًا في مجتمع React وفي مجتمع JS بشكل عام.
يوجين: ماذا تفعل بالضبط في Mendix ، هل هناك مستشارون فنيون؟- نعم. لدي العديد من الأدوار المختلفة هناك ، والأهم هو Tehlid. وهذا يعني في الأساس أنني مسؤول عن اختيار الحلول التقنية لإحدى
"قبائلنا" . وبالتالي ، أعمل على منتج يمثل بيئة لتطبيقات الهاتف المحمول. نحن نعمل على ذلك مع أربعة فرق ، وأقوم بشكل رئيسي باتخاذ القرارات المعمارية والتكنولوجية الصحيحة. بالإضافة إلى ذلك ، ما زلت برمجة. هذا جزء من عملي
والآخر هو المشاركة في مجتمع المصدر المفتوح. هذا نشاط "ذو اتجاهين". من ناحية ، نقوم بعمل أشياء فنية رائعة أريد مشاركتها في المؤتمرات ، وأتحدث بمفردي أو أشجع الزملاء على التحدث. ومن ناحية أخرى ، فإن العكس جيد في الزيارات المتكررة للمؤتمرات: تجد شيئًا يمكن أن يكون مفيدًا لنا ، ثم ندرسه وأدرجه في مجموعتنا.
يوجين: OSS Evangelism مذكور في وصف Twitter الخاص بك. ما هو ولماذا هو مهم لك؟- السبب الأول مهم: اكتشفت أنه إذا قمت بترجمة تطورك إلى مصدر مفتوح ، فلن يوفر لك الوقت على الإطلاق ، ولكنه يساعد كثيرًا في الاختبار ويحسن الجودة. لأنه يتم استخدام مكتبة مثل MobX في ظروف مختلفة جدًا. وأعتقد أنه بهذا المعنى فإن المصدر المفتوح يعطي ميزة يصعب الحصول عليها بطريقة أخرى.
والثاني: أعتقد أن مشاريعنا "ذات المستوى المنخفض" لا تحدد الشركة ، فلماذا لا نشاركها. أعني ، تصبح الشركة أكثر أو أقل تنافسية من خلال منتج يتم تصنيعه على أساس تقنياتها - وليس هذه التقنيات في حد ذاتها. ويستفيد الجميع من التعاون ، وهذا يسمح بالتسريع ككل.
يوجين: في بعض الأحيان يقولون أن المصدر المفتوح "غير النقدي" هو في الواقع متعة باهظة الثمن. تتطلب مشاريع مثل Linux الكثير من المال من عمالقة مثل Oracle و Microsoft. هل هذا صحيح؟ هل يمكن لمجتمع مفتوح المصدر أن يتواجد بدون البائعين والمال الكبيرين؟- أعتقد أن ذلك يعتمد على الوضع المحدد. هناك مكتبات صغيرة يمكن أن توجد مثل هذا. لكن مشاريع مثل Linux kernel أو React Native المذكورة أعلاه معقدة للغاية ويعتمد عليها الكثير من الناس لدرجة أنهم بحاجة إلى نموذج مالي موثوق. في هذه الحالة ، سيكون من الصعب للغاية بدون رعاة كبار. لكني لا أعتقد أن هذه مشكلة. أعتقد أنه من الأهم أن تتعلم الشركات تحمل المسؤولية مما نتعلمه بدونها.
يوجين: على سبيل المثال ، إذا جاءك Facebook وقال لك "دعنا نشتري MobX أو نرعاها حتى تخضع التنمية لعلامتنا التجارية"؟- حسنا ، في الواقع ، هم بالفعل الراعي! إنه أمر مضحك ، لكن Facebook هو أحد رعاة MobX
في Open Collective . لذلك بطريقة ما حدث هذا بالفعل. في رأيي ، Open Collective هو مثال رائع لكيفية تحسين المركز المالي للمصادر المفتوحة. يسمح للشركات برعاية التنمية بالطريقة التي تناسبها ، لأن هناك نهج جاد من الناحية المالية ، مع الفواتير وما شابه ذلك.
في Mendix ، أتقاضى الكثير من المال للعمل على MobX ، لذلك لا أرغب في التبديل إلى Facebook تمامًا. أفهم أن هذا قد يثير اهتمام شخص آخر ، لكني لا أرى مشكلة في ذلك. في رأيي ، إذا بقي الترخيص مفتوح المصدر ، فلا حرج في حقيقة أن المنتج يدخل تحت العلامة التجارية للراعي الرئيسي. الأمر أشبه بمشاهدة كرة القدم على شاشة التلفزيون: إذا كان بإمكان الجميع رؤية اللعبة ، فلن يكون هناك فرق كبير بين الشعار الموجود على القمصان.
يوجين: إذا كانت شركة كبيرة ترعى المكتبة ، ألا يمكنها أن تقول "بما أننا ندفع كثيرًا ، فالرجاء ، قم بذلك لنا فيها"؟"لم أواجه هذا ، على الأقل ، بحيث يصبح مشكلة". إذا لم أكن مخطئًا ، يستخدم Webpack مثل هذا النموذج ، فمن الممكن الدفع مقابل الميزات هناك. لذلك هناك بعض المخاطر ، ولكن أعتقد أنه من مسؤولية المشرفين التأكد من أن المشروع يبقى مخلصًا لفلسفته. ولكن ضمن هذه الفلسفة ، من المحتمل أن يكون هناك مجال كبير للمناورة. علاوة على ذلك ، في المصدر المفتوح ، إذا حدث شيء فجأة بشكل خاطئ تمامًا ، على الأقل تبقى إمكانية الشوكة.
يوجين: إن تطوير البرمجيات مفتوحة المصدر يشبه المنحنى: أولاً تقوم بإنشاء مكتبة لا يحتاجها أي شخص آخر ، ثم يبدأ الناس في استخدامها ، ثم يكتسب الآلاف من النجوم على جيثب وهلم جرا. عندما يصبح مشروع مفتوح المصدر شائعًا ، يمكن أن يستغرق الكثير من الوقت. كم تنفق على MobX؟- مؤخرًا ، ليس كثيرًا. MobX مستقر جدًا الآن. قضيت الكثير في الماضي ، بالطبع. لقد كان مختلفًا جدًا. أعتقد أنه خلال العامين الأولين كانت بضع ليال في الأسبوع ، وكانت هناك العديد من اللحظات الصغيرة عندما تقوم ببساطة بالإجابة على مشكلات أو أسئلة بسيطة على Twitter. لا تعتبر هذه الأشياء الصغيرة استثمارًا كبيرًا للوقت ، ولكن أعتقد أنها في المجموع تضيف بشكل كبير. ومع ذلك ، من الصعب جدًا قياسه. هذه هي كيفية التحقق من بريد العمل - يمكنك التحقق من المشكلة وإرسال استجابة بسرعة.
يوجين: كيف تكون منتجًا في حالة تكون فيها مطورًا ، وأنشأت مكتبة ، وأصبحت شائعة وتتطلب المزيد والمزيد من الوقت؟ أنت محظوظ ، لديك الفرصة للقيام بذلك خلال ساعات العمل. ولكن إذا كان لديك بالفعل عمل وهواية ، وأصبح المشروع أكثر شعبية؟- حسنًا ، عندما بدأت العمل على MobX ، كان ذلك أيضًا في وقت فراغي فقط ، تمت إضافة العمل عندما حقق المشروع شعبية. لكن لدي بعض النصائح. لاحظت أن هناك العديد من القواعد التي ساعدتني.
أولاً: رصد مدى ملاءمة التوثيق. إذا تلقيت نفس السؤال ثلاث أو أربع مرات ، فتأكد من تسجيل الإجابة في الوثائق. لأنه يوفر عليك الوقت.
ثانيًا: كن صعب الإرضاء حيال القضية التي تقبلها. في البداية ، بمجرد إبلاغك بخطأ ما ، فأنت تحاول إعادة إظهار المشكلة بناءً على الوصف المتاح. وفي بعض الحالات تجد أن هذا مستحيل ، وقد تم قضاء الوقت بالفعل. لذلك ، أطلب الآن شيئًا يمكنني تشغيله مباشرة من المشكلة ، سواء كان رمزًا في وضع الحماية أو طلب سحب مع اختبارات الوحدة. شيء يسمح لي بتحديد مكان المشكلة - في المكتبة أو في جانب المستخدم. هذا مهم جدًا ، لأنه يتيح لي توفير الوقت والتأكد من استعداد كاتب المشكلة لاستثمار وقتها. يقول البعض ، "ليس لدي وقت للمساعدة في إعادة إنتاج الخطأ" ، وأشعر ، "حسنًا ، ليس لدي وقت للمساعدة في حل مشكلتك". بعد كل شيء ، ربما يُدفع للشخص مقابل العمل الذي يستخدم فيه مكتبتي - فلماذا إذن يجب أن أستثمر وقتي في مشكلته؟ بشكل عام ، تساعد هذه الانتقائية ، على الرغم من أنها تجعلك تشعر بأنك أقل مسؤولية إلى حد ما ، لأنك تريد مساعدة الجميع على الإطلاق. لكنني وجدت أن "مساعدة الجميع" هو ببساطة غير واقعي.
ومع ذلك ، نظرًا لأنني أعمل مع العديد من المكتبات ، فأنا لا أستجيب لجميع المشكلات على الفور ، ولكن "الانتقال" من مكتبة إلى أخرى: أعمل عليها عدة أيام في كل مرة ، ثم انتقل إلى المكتبة التالية. ويمكنني الرد عليك في غضون دقائق إذا كتبت عن الرسالة التي أفعلها الآن ، ولكن لا يمكنني الإجابة لعدة أيام إذا لم يصل دورك بعد. هذا يساعدني على تبديل السياقات بشكل أقل.
تساعد كل هذه النصائح عندما تبدأ مكتبتك في اكتساب شعبية.
يوجين: عندما يجيب منشئ المكتبة الشعبية "لا يمكنني التكاثر ، وكتابة اختبار الوحدة" ، ألا يجعل ذلك الناس يشعرون "أنه متغطرس ولا يريد المساعدة"؟- لقد صادفت مثل هذا التأثير ، ولكن نادرًا جدًا. أعتقد أنه عادة ما يفهم المستخدم أن المشرفين مشغولون للغاية ، وأن المشكلة ذات الاحتمالية العالية في جانبه. أعتقد أنه إذا كنت تستخدم مرشح لوداش ولديك مشكلة ، فسيكون هناك شعور لا إرادي "ربما ، هناك شيء ما خطأ معي ، لأن الجميع يستخدم لوداش". لذا يفهم معظم الناس أنه يجب عليهم توخي الحذر في الأمور.
يوجين: عندما تصبح المكتبة شائعة وتتطلب المزيد من الوقت ، كم يستحق مشاركة دورك كمساهم ، مع إعطاء الحقوق لأعضاء آخرين في المجتمع؟- هذه فكرة رائعة ، وعادة ما أعطي حقوق المساهم بمجرد أن أرى العديد من طلبات السحب الجيدة من شخص واحد (أو حتى طلب سحب واحد ، إذا كان كبيرًا). في رأيي ، هذا يعمل بشكل رائع. على سبيل المثال ، في شجرة حالة MobX ، يتم الآن معظم العمل من قبل أشخاص آخرين ، وليس أنا. وهناك أجزاء أخرى من قاعدة الشفرة يفهمها الناس بشكل أفضل مني ، ومن الرائع أن كل شيء وصل إلى تلك الحالة. بالنسبة إلى MobX "الأساسي" ، هذا غير مطلوب ، لأن كل شيء قد استقر بالفعل هناك ، لم تتغير الخوارزميات على مدار العامين الماضيين ، لذا فإن عمل الدعم صغير. ولكن في حالة MobX-state-tree ، اخترت عمداً هؤلاء الأشخاص الذين قاموا بإنشاء العديد من مكتبات المستخدمين ، ومنحهم حقوق المشرف. بعد كل شيء ، إذا كنت تستخدم المكتبة بنشاط في عملك اليومي ، فسوف تصادف أنماطًا أو مشاكل شائعة فاتني. كما أعتقد أنه يمنح المطورين حافزًا وشعورًا بالوثوقية - لأنهم يمكنهم مساعدة المكتبة على العمل بما يواجهونه.
يوجين: في الوقت نفسه ، ألا يوجد شعور بأن المكتبة ، كطفل ، تتعرض للضرب؟ ربما لا توافق على كيفية تطويرها من قبل أشخاص آخرين بالضبط؟- في بعض الأحيان يحدث ذلك قليلاً. ولكن أعتقد أن هذا أمر طبيعي. لقد أجريت تشابهًا كبيرًا مع الأطفال: بمرور الوقت ، يكبرون ويصبحون 18 عامًا ، ثم تحتاج إلى السماح لهم بالرحيل ، لأنه حان الوقت للعثور على طريقهم الخاص. أعتقد ، إلى حد ما ، مع مكتبات مفتوحة المصدر أيضًا. إذا كانت ناجحة ، فإنك تبدأ في مواجهة مواقف أكثر صعوبة. تبدأ في التعامل مع الحالات التي لا أريد التعامل معها بشكل عام. لن يكون الرمز بعد الآن هو الرمز الجميل والنظيف والأضيق الذي أردت في الأصل. هذا أمر لا مفر منه.
لدى MobX مثال رائع على ذلك: لقد كتبت في الأصل لـ TypeScript ، حيث الديكور بسيط جدًا ، ثم بدأ الناس في استخدامه مع Babel ، حيث يوجد تنفيذ مختلف تمامًا. وفي النهاية ، تكون بعض أجزاء قاعدة التعليمات البرمجية قبيحة للغاية لأنها تحاول تحديد ما إذا كنت تستخدم TypeScript أو Babel. يبدو فظيعًا ويبدو فظيعًا. لكن هذا جزء من العمل. ليس من الضروري أن تحبها ، ولكن من الضروري التأكد من أن كل شيء يعمل بشكل جيد في كل مكان. وبهذا المعنى ، يمكن لطفلك أن يسير في اتجاه لم تفكر فيه ، ولكن هذا طبيعي ، لأنه في النهاية من المهم أن يتمكن الأشخاص من استخدام المشروع بنجاح.
يوجين: التطور يتغير ، أصبح الكثير أسهل مما كان عليه قبل 10-20 سنة. ما رأيك في الوضع الحالي في المصدر المفتوح فيما يتعلق بهذه التغييرات ، وماذا تتوقع من المستقبل؟ هل ستصبح الشركات الكبرى تغذي الجميع ، أو على العكس من المتحمسين؟- هذا سؤال صعب. لست متأكدا أنه ستكون هناك تغييرات كبيرة. وهناك تغييرات في كلا الاتجاهين دفعة واحدة. أنا معجب بشكل خاص بفيسبوك ومايكروسوفت - كم يفتحون الآن وإلى أي مدى يسمحون لمطوري الطرف الثالث بالمساهمة. React Native هو مثال مدهش بشكل خاص حيث لا يأتي جزء كبير من العمل من Facebook. من ناحية أخرى ، بالنسبة للوحيد ، ربما لم يكن من السهل أبدًا المشاركة في مشروع مفتوح المصدر أو إنشاء مشروعك الخاص ، كما هو الآن. أصبحت الأدوات أكثر توحيدًا ، ولدينا
IDE رائعة عبر الإنترنت مثل
CodeSandbox و
Gitpod . لقد كنت أعمل مع Gitpod في الأسابيع الأخيرة ، وهذا أمر رائع: يمكنني التحقق من طلبات السحب دون القيام بأي شيء محليًا. يمكنك ببساطة تشغيل Docker في متصفح وتطويره. لذلك لا أعرف ما هي التغييرات.
يوجين: قبل ثماني سنوات ، عندما كنت مطورًا لـ C ++ ، لم يكن هناك مجتمع مفتوح المصدر مثل الآن. والآن في عالم الويب وجافا سكريبت ، أرى أن المصدر المفتوح يتطور بشكل أسرع وأسرع. هل سيستمر هذا النمو؟- أعتقد أن الحركة ستستمر. أحد الأسباب ، في رأيي ، هو ما يلي: كل من الشركات والمطورين يتفهمون بشكل متزايد أن المصادر المفتوحة ليست مفيدة فقط لمن يقومون بتطويرها أو استخدامها ، ولكنها تساعد أيضًا في العثور على موظفين. بالنظر إلى مشاركة الشخص في المصدر المفتوح ، يمكنك أن تفهم عنه أكثر مما لو أجريت معه مقابلة طوال اليوم. تظهر الطريقة التي يجيب بها عن المشكلة أو يبدأها كثيرًا. أعتقد أن المطورين والشركات أصبحوا على وعي متزايد بأهمية هذا.
يوجين: هل تعتقد أن تطوير مكتبة مفتوحة المصدر يمكن أن يساعد في المقابلة؟- بالضبط. إذا كنت شركة ولديك مثل هذه المكتبات غير المرتبطة ارتباطًا وثيقًا بواجهة برمجة التطبيقات الخاصة بك ، فهذا أمر رائع ، لأن الأشخاص سيأتون للمشاركة - وقد يتحولون إلى ما تحتاج إليه بالضبط. وإذا عينت أحد المساهمين لديك ، فسيكون من السهل عليهم الانضمام ، وستفهم بشكل أفضل ما تتوقعه. أعتقد ، لهذا السبب وحده ، تم فتح الكثير من الأشياء المثيرة للاهتمام.
ديمتري: تحدثنا عن المصادر المفتوحة بشكل عام ، دعنا ننتقل بشكل خاص إلى MobX. كيف ولماذا بدأت تفعل ذلك في البداية؟- سؤال جيد. لدينا في Mendix منذ فترة طويلة تطبيق Windows مكتوب بلغة C #. قبل بضع سنوات ، قررنا نقله إلى الويب وبدأنا في تحديد المكدس الذي سنستخدمه. كان رد الفعل قد بدأ للتو ، وكان Angular موجودًا منذ فترة ، وكان Ember شائعًا جدًا. وبسرعة كبيرة ، وقعنا في حب شركة React بسبب نموذجها المكون وطبقة التجريد المقترحة.
ولكن بعد ذلك وجدنا أن لدينا مشكلة في الأداء ، اتضح أن تحديث DOM كان مكلفًا للغاية ، حتى في حالة React. في C # ، قمنا باستمرار بتحديث النموذج وإعادة رسم اللوحة بأكملها ، ولم يقم أحد بتحسين أي شيء ، لأن كل شيء يعمل بسرعة كبيرة على أي حال ، لذلك لم يكن من الضروري "الاقتراب من العرض بطريقة ذكية". ولكن هنا وجدنا أنه في حالة DOM ، لا يمكنك إعادة رسم كل شيء 60 مرة في الثانية. لذلك فكرنا في كيفية القيام بذلك بشكل فعال. فكرنا في النهج غير القابل للتغيير ، ولكن في حالتنا لم يكن مناسبًا لعدة أسباب. واحد منهم هو البيانات التي عملنا معها وكيف تم تقديمها. تم تقديم نفس المعلومات في أماكن مختلفة. من الصعب جدًا تطبيع بياناتنا. وثانيًا ، يبدو أنه لا يزال عليك التعامل مع الكثير من التفاصيل. على سبيل المثال ، يجب عليك كتابة محددات للبيانات التي تعرضها.
ولكن ماذا لو كنت تريد كتابة نفس الرمز البسيط مثل رمز C # الخاص بنا ، "تقديم شيء ما" من قبل ، ولا تريد أن تهتم بكيفية تغير هذا في المستقبل؟ إذا كنت لا تريد أن تقول للمكونات "إذن ، خذ هذا الجزء من البيانات من هنا ، ولكن هذا من هناك ، وبعد ذلك يمكنك تقديم شيء"؟ بدأنا في دراسة التقنيات المتاحة حاليًا ، ووصلنا بسرعة إلى النموذج المستخدم في Knockout و Meteor و (على الأقل المفاهيمي) حتى في Angular. حيث لا تقصد إما العلاقة بين تبعيات البيانات ومكوناتها ، أو ما يجب تقديمه متى.
بدأت أفهم لماذا يكره الناس غالبًا مثل هذه الأساليب ، خاصة عندما ينمو التطبيق. واتضح أنه في كثير من الأحيان يشعر الناس بالقلق من عدم القدرة على التنبؤ و "تصحيح الأخطاء" ، وأن شيئًا ما يمكن القيام به كثيرًا ، أو نادرًا جدًا ، أو في ترتيب خاطئ. وقررت أنه يمكننا القيام بعمل أفضل. يمكننا أن نسعى لتحقيق نفس الهدف ، ولكن اتباع نهج أذكى في التنفيذ. وهكذا ظهر MobX. لا يقتصر الأمر على التقاط العلاقة بين الملاحظات والملاحظات ، ولكنه يبني رسمًا بيانيًا كاملًا للاعتماد ، لذلك يمكنك التأكد من تنفيذ جميع المراقبين بالترتيب الأكثر كفاءة. في البرمجة التفاعلية ، هناك مفهوم "خلل" - وهكذا ، هنا لا يمكن أن يحدث. بشكل عام ، تم أخذ واحدة موجودة هنا ، ولكن في محاولة لجعلها أكثر قابلية للتنبؤ.
ديمتري: هذا ، إذا أحببت نوعًا ما من النهج ، لكن المكتبات الحالية ليست جيدة بما يكفي ، يمكنك فقط اتخاذ أفضل ما يمكن ، وهذا يمكن أن يصبح شائعًا؟- نعم بالضبط! لذا كتبت ذلك في البداية لأغراضنا الداخلية ، ثم ذهبت إلى ReactEurope. يبدو أنه عام 2015 ، وكان هناك الكثير من الحديث عن أنماط التدفق. ثم اندلعت حروب الجريان. وشعرت أن الناس يبذلون الكثير من الطاقة في مشكلة قمنا بحلها بالفعل.
ثم فكرت "أنا بحاجة إلى الانفتاح". وعملت. ربما لأنه لم يكن "تنفيذ Flux آخر" ، بل كان شيئًا مختلفًا تمامًا. لقد كان مفيدا لكثير من الناس.يوجين: كانت الفكرة الأصلية لـ MobX بسيطة ، ولكن الآن هناك الكثير من التعليمات البرمجية والميزات. هل هناك شعور بأن كل شيء معقد للغاية؟— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 ,
Proxy .
: Proxy. - , . ?- في بعض الأحيان ليس من السهل أن تكون أحد المشاريع الأولى التي يتم استخدامها ، ولكن ظهر الوكيل منذ فترة طويلة ، ظهر التنفيذ المستقر قبل حوالي أربع سنوات. وقبل عام واحد فقط تم تنفيذها في جميع المتصفحات. ظهر التنفيذ الأساسي في Chrome 8 ، ولكن استخدامها في وقت سابق كان يعني زيادة كبيرة ، ولكن الآن تغير.يوجين: دعنا نتحدث عن الشرط. نتذكر الأيام التي كان فيها jQuery ملكًا لتطوير الويب ، وبعد ذلك لم نكن نتحدث عن الحالة على العميل ، قمنا بتخزينها في كائن عالمي أو شيء من هذا القبيل. الآن ، لا يمكنك إنشاء تطبيق بدون مكتبة رسمية مثل Redux أو MobX. ما الذي تغير؟— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .
وأعتقد أن إدارة الدولة فعلت للدولة ما فعله React لواجهة المستخدم. تسمح لك إدارة الدولة بتقسيم ولاياتك إلى أنماط أكثر تماسكًا. يمكنك استخدام مجموعات البيانات والمنطق المستقلة ، واختبار الوحدة بدون واجهة مستخدم والتحكم فيها بشكل أفضل.يوجين: ما رأيك بمستقبل إدارة الدولة؟ لقد وصلنا بالفعل إلى النقطة حيث لا يوجد شيء آخر نضيفه إليه؟"أعتقد أننا لم نصل إليها بعد." خاصة عندما يتعلق الأمر بإدارة الدولة التي تركز على القيم الثابتة. أعتقد أن أحد الأسباب التي أصبحت مغمورة جدًا لهذا العام هو أنه جعل تحديث الحالات غير القابلة للتغيير أكثر محلية لـ JS. لكن أعتقد أن هناك الكثير الذي يمكن القيام به في إدارة الدولة. على سبيل المثال ، يستخدم معظم الأشخاص المحددات أوالعدسات ، ولكن يبدو لي أنها ليست مريحة للغاية. أعتقد أن هناك المزيد والمزيد من المناهج التي تظهر ، على سبيل المثال ، من المثير للاهتمام للغاية أن نذكر GraphQL ، على الرغم من أنها ليست مريحة للغاية عندما تحتاج إلى العمل مع الولايات المحلية. لذلك لا يزال لدينا مجال للنمو ...يوجين: هل يمكنك تسمية ميزة أو اثنتين تود إضافته إلى MobX؟- هناك شيء واحد أود القيام به ، ولكن أخشى أنه لن يحتاجه الجميع. أود جعل تحويلات البيانات أكثر تفاعلاً. أعني هذا: لنفترض أن لديك قائمة مهام بسيطة وتقوم بتطبيق التصفية عليها. يجب أن يظهر الفلتر ، على سبيل المثال ، جميع المهام التي لم تكتمل. تكمن المشكلة في أنه إذا تغير شيء ما ، فيجب أن يقوم المرشح بالتكرار على جميع عناصر المهام في القائمة ، بينما يمكن معالجة العناصر المتغيرة فقط. والآن لا توجد طريقة ملائمة للتعبير عنها. ولكن من حيث المبدأ ، يمكن جعل تحويلات البيانات أكثر تفاعلية مما هي عليه الآن.دميتري: مؤلفو المكتبات الشعبية مدعوون للتحدث في المؤتمرات وإجراء التدريبات. أود أن أسأل عن التدريب. في روسيا لا يحبونهم ، مع الأخذ في الاعتبار شيء للمبتدئين. ما هو موقفك وما الذي تواجهه في أوروبا؟- أحب التدريب حقًا ، وأعتقد أنها طريقة رائعة للتعلم. أنا شخصياً أحب أن أتعلم بإحدى طريقتين: إما أن أجلس وأقرأ كتاباً من الغلاف إلى الغلاف ، أو أن آتي إلى التدريب. مقاطع الفيديو ليست لي ، فهي دائمًا إما بطيئة جدًا أو سريعة جدًا. على الرغم من أنني أنشأت العديد من دورات الفيديو ، لم يعجبني ذلك. عندما بدأت تعتاد على Docker ، ذهبت إلى التدريب. وبما أن هذا درس عملي للغاية ، ستشعر على الفور كيف يعمل كل شيء ، وكيف هو وكيف يمكنك تطبيقه. بالنسبة لي ، التدريب ليس "للصغار". في رأيي ، الشيء الرئيسي فيها هو أن هذه هي أسرع طريقة لإتقان تقنية جديدة لم تكن مألوفًا بها بعد. أعتقد أن هذه هي القيمة الرئيسية ، ولن تحصل على هذا من الكتاب. يتحدث الكتاب بشكل أكبر عن الصورة الكبيرة ، التي يمكنك من خلالها فهم مدى صلة شيء ما بك على الإطلاق.ولكن إذا كنت تريد حقًا البدء في العمل مع شيء ما ، أو تفكر بجدية في هذا الخيار ، فسيكون التدريب هو الأسرع. هناك ، خلال فترات الراحة ، يطرح الناس أسئلة محددة حول الصعوبات المحددة التي واجهوها ، أو يسألون عن تطبيق ما تعلموه في وضعهم الخاص. هذه هي ميزة التدريب: يمكنك التحدث مع شخص ما وطرح أسئلة خاصة بموقفك. أنا أؤمن حقًا بهذا الشكل من إتقان التقنيات الجديدة.أنا أؤمن حقًا بهذا الشكل من إتقان التقنيات الجديدة.أنا أؤمن حقًا بهذا الشكل من إتقان التقنيات الجديدة.: ( , ) , , Medium YouTube. ?- أعتقد ، على عكس الدورات التدريبية ، أن الهدف الرئيسي للمؤتمر ليس التدريب. على أي حال ، رأيي الشخصي. السبب الرئيسي للذهاب إلى المؤتمر هو الحصول على الإلهام. ما يحدث في الصناعة ، ما يفعله الناس ... يريدون التعلم. إلى جانب ذلك يأتي التواصل. عندما تأتي إلى مؤتمر مع الزملاء ، حاول ألا تتحدث معهم كثيرًا. أنت تعرفهم بالفعل. أنت تعرف ما هي المشاكل التي يحلونها. من المثير للاهتمام التحدث مع أشخاص عشوائيين ، على سبيل المثال ، الوقوف في الطابور للحصول على الطعام. يمكنك أن ترى ما يفعلونه ، وما هي المشاكل التي يحلونها ، وما لديهم من خبرة مع المكتبة ، والتي تحدث عنها شخص ما في الصباح. وابحث عن المتحدثين إذا كان لديك أسئلة لهم. يخاف الكثير من الناس من الاقتراب من المتحدثين ، ولكن بالنسبة لي كمتحدث (وأعتقد ،بالنسبة لمعظم المتحدثين الآخرين) التواصل مع الجمهور هو مجرد جزء مثير للاهتمام من المؤتمر. حسنًا ، من الأفضل عدم الاتصال بي قبل خمس دقائق من الصعود إلى المنصة ، لكن ما تبقى من الوقت أحاول الوصول إليه بسهولة. لذلك لا تشعر بالحرج والاتصال.يوجين: نصيحة عظيمة. ستكون في روسيا للمرة الأولى - ماذا تتوقع من موسكو ومن المؤتمر؟- أريد بالتأكيد أن ألقي نظرة على موسكو وسأصدم بالتأكيد. ولقد لاحظت أيضًا أن هناك العديد من مستخدمي MobX في روسيا. أرى هذا على تعقب ، في الالتزامات. لذا آمل أن ألتقي بالعديد من مستخدمي MobX في المؤتمر.يمكنك أن ترى ميشيل وتطرح عليه أسئلة في HolyJS 2018 موسكو ، والتي ستعقد في 24-25 نوفمبر . هناك سيتحدث أكثر عن إدارة الدولة. عرض وصف لتقارير المؤتمر على موقعه على الإنترنت .