لماذا TypeScript هي أفضل طريقة لكتابة الواجهة الأمامية في عام 2019

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

تحصل TypeScript على المزيد والمزيد من الشعبية في بيئة الواجهة الأمامية. 80٪ من المطورين يعترفون بالفعل أنهم يرغبون في استخدام أو تعلم TypeScript في مشروعهم التالي. نفسي ، لقد أحببته منذ أن استخدمته لأول مرة. وسأستمر في استخدام هذا في جميع مشاريعي القادمة بالتأكيد.

يثير بعض الناس مخاوف من أن TypeScript هو تبعية غير ضرورية لسلسلة الأدوات الأمامية. فعلا؟ اتبعني لمعرفة أن الواقع هو عكس ذلك تماما.

قصة "رجل اللغات المكتوبة ديناميكيًا"

طوال أكثر من 18 عامًا من مسيرتي المهنية في البرمجة ، لم أحب أبدًا اللغات المكتوبة بشكل ثابت. منذ أن بدأت البرمجة في عام 2001 ، كانت لغتي المفضلة دائمًا مكتوبة ديناميكيًا: PHP و JS و Ruby و Elixir. كنت قد فعلت بعض البرامج في C ++ و Java هنا وهناك ، لكنني كرهت دائمًا تلك البيئات. ("لماذا أحتاج إلى تمرير النوع في كل مكان؟ هذا يرضع. يمكنني الاعتناء بهم بنفسي.")

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

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

الآن يجب أن أعترف. لا أحب اللغات المكتوبة ديناميكيًا بعد الآن. لا يزال بإمكاني العمل بفعالية كبيرة فيها ، لكن هذا يجعلني غير سعيد عندما لا يمكنني البحث عن تعريفات النوع في IDE ، أو الثقة في المترجم أثناء إعداد النماذج الأولية للرمز. (الشيء الوحيد الذي ما زلت أفتقده في Elixir هو أنواع قوية).

لحسن الحظ ، لا يتعين علينا الانتظار حتى تقوم لجنة Ecma TC39 بتقديم نظام الكتابة الثابتة في JavaScript. يمكننا استخدام TypeScript بدلاً من ذلك. خاصة في المشاريع الجديدة ، عندما تكون متاعب استخدامه ضئيلة للغاية.

وسيطات مكافحة TypeScript

ومع ذلك ، لا يزال البعض يجرؤ على القول بأن جلب TypeScript إلى مشروعك سوف:

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

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

لهذا السبب قررت أن أكتب هذا المقال. ربما سيساعد ذلك في إقناعك ، أصدقاءك ، زملائك في العمل ، أو مدير مكتب التسويق ، بهذه اللغة الرائعة.

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

  • "ما هو برنامج TypeScript ولماذا أستخدمه بدلاً من جافا سكريبت؟" - Lodewijk's Bogaards ، StackOverflow
  • الموقع الرسمي للغة TypeScript
  • "TypeScript - JavaScript مع القوى العظمى" - Indrek Lasn ، متوسطة
  • "TypeScript Deep Dive" - ​​كتاب إلكتروني لباسارات علي سيد

مزايا TypeScript

1. رمز أسهل للفهم

عادةً عندما تعمل على جزء من التعليمات البرمجية ، على سبيل المثال رمز دالة ، لفهمها تمامًا ، فأنت بحاجة إلى فهم:

  1. ما الحجج التي تقبلها؟
  2. ما هي القيمة التي تعود؟
  3. ما هي البيانات الخارجية التي تتطلبها؟
  4. ماذا تفعل مع هذه الوسائط والبيانات الخارجية لإنتاج القيمة المرجعة؟

في اللغات المكتوبة ديناميكيًا ، يصعب في كثير من الأحيان الإجابة على الأسئلة الثلاثة الأولى. إذا تلقت الدالة وسيطة المقالة ، فما هو بالضبط؟ هل هو كائن مع بعض سمات المادة؟ ما هي السمات الدقيقة هناك؟ هل هناك article.title أو article.name؟ هل يمكنني دائمًا افتراض أن عنوان article.title موجود؟ ماذا عن article.isPublished؟ قد أعلم أن هذه السمة مدمجة في كائن المقالة في معظم أماكن التطبيق ، لكن هل يمكنني التأكد من أنها موجودة دائمًا في هذا المكان أيضًا؟

للإجابة على كل هذه الأسئلة ، عادة ما تحتاج إلى القيام بأي مما يلي:

أ) ضع console.log (مقالة) ، وقم بتشغيل البرنامج النصي في متصفحك ، (ربما انقر فوق واجهة المستخدم قليلاً) ، واقرأ السجل ؛

ب) معرفة أين يتم استخدام الوظيفة ومن هناك تعقب البيانات التي يتم وضعها في جميع حالاتها ؛

ج) اسأل زميلك الذي كان يعمل مؤخرًا على هذا الرمز (معربًا عن أمله في أنه لا يزال على قيد الحياة ، عبر الإنترنت ، وتذكر هذا الرمز) ؛

د) افترض أن المقالة تشبه ما تعتقد أنه مجرد أمل في أن تنجح.

هل هذا يبدو مألوفا بالنسبة لك؟

بالنسبة لي ، يبدو هذا كأنه سير عمل ديف ويب نموذجي بأي لغة مكتوبة ديناميكيًا مثل JS و PHP و Ruby و Python و Elixir.

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

2. رمز أسهل وأسرع لتنفيذ

عادةً ، عندما تضطر إلى إنشاء ميزة جديدة أو مكون جديد ، فمن المحتمل أن يبدو سير العمل لديك كما يلي:

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

في TypeScript ، إنه مشابه ، لكنه أسهل وأسرع:

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

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

3. رمز أسهل ل refactor

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

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

إعادة تسمية

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

في اللغات المكتوبة بشكل ثابت ، لم تعد هناك حاجة إلى البحث والاستبدال. باستخدام أوامر IDE مثل "Find All Occurrences" و "Rename Symbol" ، يمكنك رؤية كل التكرارات في تطبيق الوظيفة أو الفئة أو خاصية واجهة واجهة الكائن.

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

4. أقل البق

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

يسعدني أن أخبرني أنني قابلت هذا الصديق أخيرًا: يطلق عليه TypeScript.

بفضله ، أصبح من الصعب الآن كتابة رمز غير صالح. إذا تم تجميعها ، فقد تكون متأكدًا من أنها تعمل بالفعل.

5. اختبارات أقل المرجل

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

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

تعني الاختبارات الأقل وقتًا أقصر لتطوير ميزات جديدة وقاعدة بيانات أصغر ، والتي بدورها أقل تعقيدًا وأقل عرضة للخطأ وأسهل في الصيانة.

6. رمز أسهل لدمج

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

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

إذا كان لديك TypeScript في سلسلة الأدوات الخاصة بك ، فهو يوفر لك فحص ضمان آخر: فحص تجميع typedef.

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

TypeScript يجعل من الأسهل الثقة بالمطورين الآخرين. قد يؤدي ذلك إلى تحسين وتيرة مراجعة PRS ودمجه.

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

7. يساعد المطور في الحصول على سير العمل الصحيح

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

سيراهن الكثير من الناس على أن هذا هو سير العمل الترميز الصحيح.

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

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

نفس الشيء ينطبق على TypeScript. يشجعك على التفكير في واجهة الشفرة الخاصة بك قبل البدء في تنفيذها الداخلي.

مخاوف TypeScript

1. "سيضر تجنيدنا"

فإنه سوف؟

تُظهر استطلاعات JS العادية بوضوح أن عددًا أكبر من الناس يقومون بالبرمجة في TS أو على استعداد لتجربتها.

https://2018.stateofjs.com/javascript-flavors/typescript/

يثبت الاستبيان أعلاه أنه: اعتبارًا من عام 2018 ، يرغب 80٪ من مطوري الواجهة الأمامية في العمل في TypeScript.

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

2. "على متن الطائرة سيستغرق المزيد من الوقت"

الحقيقة هي ، على الرغم من أن TypeScript هي مجموعة شاملة من JavaScript ، إلا أنه شيء جديد يجب على الجميع تعلمه. سيتعين على مطور غير مألوف من TS أن يقرأ عنها لمدة ساعة أو ساعتين على الأقل ، قبل البدء في التعاون في مثل هذا المشروع.

على العكس من ذلك ، إذا كان لديك مشروع تم إنشاؤه بالفعل في TypeScript ، فسيكون من السهل جدًا على المطورين الجدد أن يندمجوا فيه. TS Syntax بديهي ويسهل فهمه للغاية (وهذا على الأرجح هو السبب وراء حصوله على شعبية كبيرة). وظيفة عامة واجهات ، نوع الحرس ، أنواع الشرطية؟ لن تضطر للمس ولم تفهم أبدًا 99٪ من عملك اليومي. 1٪ المتبقية هي عادة شيء يجب القيام به فقط في البداية ، ويمكن إعداده بواسطة مبرمج TS يجيد بالفعل.

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

3. "React / Redux و TS لا يناسب كل منهما الآخر"

عنصر زر في رد الفعل و TypeScript

خاطئة. كان TS الدعم TSX منذ فترة طويلة. أيضًا بفضل الأنواع العامة البسيطة مثل React.Component ، يمكنك التخلص من PropTypes واستخدام نظام الكتابة الحقيقي بدلاً من ذلك.

صحيح أنه قبل حوالي عام ، كان مطلوبًا كتابة جزء من التعليمات البرمجية النقطية لجعل TypeScript يعمل مع منشئي عمل Redux. ولكن منذ إصدار TS 2.8 في فبراير 2018 ، لم تعد هذه هي الحالة. يمكنك الحصول على كود React / Redux المكتوب والبسيط في TypeScript. تعمل FYI أو React Context أو Hooks بدون عيوب مع TypeScript.

4. "سيكون من المستحيل إعادة استخدام كود JS في تطبيق TS"

مرة أخرى ، خطأ. أي رمز JS هو رمز TS صالح.

صحيح ، إذا كنت تستخدم TS في وضع صارم (noImplicitAny) ، فسيتعين عليك إضافة بعض الأنواع هنا وهناك لجعل رمز JS يعمل. لكن هذا كل شيء! يوجد أيضًا مكون إضافي IDE يمكنه تلقائيًا تحويل مكونات JS React مباشرة إلى TS.

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

5. "باختيار TypeScript ، قد ينتهي بنا الأمر إلى قفل بعض الأدوات القديمة ، والتي لن يدعمها أحد في المستقبل"

تُستخدم TypeScript في الوقت الحالي بواسطة Microsoft و Asana و Lyft و Slack وجميع مطوري Angular 2+ ومطوري React & Vue.js المتعددة وآلاف الشركات الأخرى. العديد من الآخرين ينضمون إليهم كل يوم. TypeScript هي المجموعة الأكثر شعبية في JS في الوقت الحالي ولن تنخفض في أي وقت قريب.

ما هي فرصة التخلي عن هذه اللغة؟

أود أن أقول ما يقرب من الصفر. السيناريو الوحيد الذي يمكن أن يموت فيه TS هو إذا كانت JS ستجلب أنواعًا إلى لغتهم من تلقاء نفسها. ولكن هذا لن يحدث في أي وقت قريب بالتأكيد. على الأقل ليس في السنوات القادمة ~ 5-10. في الحالة النادرة التي قد تحدث بالفعل ، يمكنك التأكد من وجود أدوات تتيح لك الترحيل بسهولة من TS إلى JS المكتوب.

من 5 إلى 10 سنوات من الآن قد يكون الوقت الذي لم يعد فيه أحد يعرف React أو Vue أو Angular. لكنك لا ترى مشكلة في التمسك بتلك الأطر التي أعتقدها؟ ؛)

6. "ماذا عن التدفق؟"

يوفر لك TypeScript نفس الشيء الذي يفعله Flow والمزيد. بل هو أيضا وسيلة أكثر شعبية.

تنزيلات TS مقابل Flow npm على مدار العامين الماضيين (npmtrends.com)

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

بعد فوات الأوان ، كان Flow شائعًا مثل TS منذ حوالي 3 سنوات ، عندما كان كلاهما لاعبين جدد في السوق. تم دفع أحدهما من قِبل Microsoft والمجتمع Angular ، بينما تم تفضيل الآخر بواسطة Facebook وبعض مجتمع React.

فاز TypeScript في النهاية. في أيامنا هذه ، يتحول المزيد والمزيد من المطورين من جميع الأطر الأمامية إلى TypeScript.

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

سلبيات TypeScript

1. يتطلب خطوة تجميع

أخبرني بعض أصدقائي في Node.js الخلفيين أن تقديم TS لهم لا يستحق كل هذا العناء ، لأنه سيؤدي إلى الكثير من المتاعب مع الحاجة إلى تجميع جميع ملفات .ts قبل تشغيلها على Node.

على الرغم من أنه من المؤكد أنه يمكنك التعامل مع الإعداد الجيد للبناء والتطوير ، إلا أنني لا أوافق على أنه يضيف القليل من النفقات العامة إلى تطبيق Node.js الخاص بك.

لا يمكنني الموافقة على ذلك في بيئة الواجهة الأمامية. الجميع يجمع JS في الواجهة الأمامية هذه الأيام. تحتاج إلى دعم المتصفح القديم؟ ميزات ES7؟ CSS-في-JS؟ لكل هذه ربما كنت بالفعل تستخدم بابل. يمكن تجميع TypeScript مع Babel ، تمامًا مثل أي صيغة أخرى لـ JS (بما في ذلك ES7 أو JSX).

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

2. قليلا من الصعب اقامة

يمكن أن أتفق على ذلك. على سبيل المثال ، ما الفرق بين تطبيق Next.js وتطبيق Next.js في TypeScript؟ في الحالة الثانية ، تحتاج إلى جعل خادم Node.js وحزمة الويب ومرشح اختبار jest للعمل مع TypeScript. وأيضًا ، عندما تضيف بعض المكتبات مثل React و Redux و Styled-Components ، فإنك تحتاج أيضًا إلى إضافة typedefs لها ، مثل npm i @ types / styled-components (إلا إذا كان لدى lib ملف TS typedefs مدرج فيه).

السؤال الذي تحتاجه للإجابة على نفسك ، كم مرة تفعل هذا الشيء؟ هل هذا كثير من الجهد ، ليكون جديراً بالاستقالة من جميع مزايا TypeScript؟

ملخص

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

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

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

دعونا نفعل الناس TypeScript

الروابط

حول TypeScript

  • "ما هو برنامج TypeScript ولماذا أستخدمه بدلاً من جافا سكريبت؟" - Lodewijk's Bogaards ، StackOverflow

"التحول إلى TS" استوديوهات القضية

  • "TypeScript في Lyft" - محسن عظيمى ، متوسط
  • "TypeScript at Slack" - Felix Rieseberg، Medium
  • "كيف قمنا بترحيل مشروع 200K + LOC إلى TypeScript ونجينا من سرد القصة" - Kleo Petrov، Hashnode
  • "تحويل 600 ألف خط إلى TypeScript في 72 ساعة" - Paul Draper & Ryan Stringham، LucidChard TechBlog

استعراض الآخرين من TS

  • "7 أعذار سيئة لعدم استخدام TypeScript" - ديمتري باشكيفيتش ، متوسط
  • "لماذا استخدام TypeScript ، الأسباب الجيدة والسيئة" - Charly Poly ، Medium
  • "JavaScript مقابل TypeScript مقابل ReasonML" - د. أكسل راوشماير ، 2ality
  • "طباعة - لماذا يجب أن يستخدمها؟" - ماجد ، متوسط
  • "لماذا ينمو برنامج TypeScript أكثر شيوعًا" - ماري برانسكومب ، المكدس الجديد