【译】为什么TypeScript是2019年编写前端的最佳方式

【译】为什么TypeScript是2019年编写前端的最佳方式

技术杂谈小彩虹2021-07-08 13:36:4690A+A-

原文链接

TypeScript在前端环境中越来越受欢迎。已经有80%的开发人员承认他们想在下一个项目中使用或学习TypeScript。自从我第一次使用它以来,我就一直喜欢它。我肯定会在以后的所有项目中继续使用它。

有些人担心TypeScript是前端工具链的不必要依赖。是吗?跟着我来了解现实是完全相反的。

一个“动态类型语言专家”的故事

在我编程生涯的18年中,我从未喜欢过静态类型的语言。自从2001年开始编程以来,我一直选择动态选择语言:PHP,JS,Ruby,Elixir。我到处都用C ++和Java编写了一些程序,但是我一直讨厌那些环境。(“为什么我需要在各处传递类型?这太糟了。我自己可以照顾他们。”) 一切都在2年前发生了变化。那是我第一次使用TypeScript的时候。但是,从一开始我就没有爱上它。在最初的几天里,这实际上让我很烦。情况很快改变了。我在代码中输入的类型定义越多,我越经常注意到它使我免于浪费时间在控制台中手动调试愚蠢的bug。我开始欣赏这些类型。 在接下来的两年中,无论何时我在前端应用程序上进行协作,无论是Angular还是React,我都注意到,无论我使用什么框架,在所有.js项目中总会遗漏一件事:TypeScript 。 现在我必须承认。我不喜欢动态类型的语言了。我仍然可以在其中高效地工作,但是当我不能只在IDE中查找类型定义或在对代码进行原型设计时信任编译器时,这使我感到不满意。(我在Elixir中唯一仍然想念的是强类型。) 幸运的是,我们不必等到Ecma TC39提交者将静态类型系统引入JavaScript。我们可以改用TypeScript。特别是在新项目中,使用它的麻烦极少。

反TypeScript参数

尽管如此,仍然有人敢于争辩说将TypeScript引入您的项目将:

  • 增加新开发人员的入职时间,
  • 维护复杂化
  • 与React发生很多冲突,
  • 增加开发时间,
  • 将项目锁定到一年后将不再存在的某些时髦技术中,
  • 阻止招募优秀的JS人员,
  • 使得不可能从非TS代码库中引入代码,
  • 使得在遥远的将来很难编辑该应用。

我敢说他们都错了。TypeScript将为您解决以上所有情况,我可以为您提供具体的论据,为什么会这样。 这就是为什么我决定写这篇文章的原因。也许这将有助于说服您,您的朋友,同事或CTO使用这种出色的语言。 注意:在本文中,我不会解释“ TypeScript是什么”。我仅关注“ 为什么”您应该使用它。如果您仍然不了解TypeScript的真正含义,建议您首先阅读以下一些链接:

TypeScript的优势

1.代码更容易理解

通常,当您处理一段代码(例如功能代码)时,要完全理解它,您需要掌握以下内容:

  1. 它接受什么论点?
  2. 它返回什么值?
  3. 需要什么外部数据?
  4. 为了产生返回值,这些参数和外部数据有什么作用?

在动态类型语言中,通常很难回答前三个问题。如果一个函数收到article参数,那么它到底是什么?它是具有某些商品属性的对象吗?有哪些确切的属性?是否有一个article.titlearticle.name?我可以始终假设article.title存在吗?怎么article.isPublished样我可能知道此属性article在应用程序的大多数位置都已合并到对象中,但是我可以确定,它始终也存在于此位置吗?

要回答所有这些问题,通常需要执行以下操作之一:

  1. console.log(article)在浏览器中放置一个,运行脚本,(也许单击一下UI),然后阅读日志;
  2. 查看该函数的使用位置,并从那里跟踪将哪些数据放入所有出现的位置;
  3. 向您的同事询问最近是否正在使用此代码(希望他们仍然健在,在线并记住该代码);
  4. 假设它article与您所想的一样,只是希望它能起作用。

这听起来对您熟悉吗?

对我来说,这听起来像是任何动态类型化语言(例如JS,PHP,Ruby,Python,Elixir)中的典型Web开发工作流程。 在诸如TypeScript之类的静态类型语言中,您可以立即从IDE和编译器中获得上述所有问题的答案。您不再需要查看整个代码库,让同事困扰于问题,也不必冒生产中的错误的风险。

2.代码更容易实现

通常,当您必须创建新功能或新组件时,您的工作流程可能如下所示:

  1. 引导组件函数,组成其构造函数参数,编写其余代码。
  2. 如果它需要任何外部或复杂的数据(如user或articles),请猜测它的外观,将其保存在自己的内存中,并像在代码中那样使用它。
  3. 将组件放到您的应用中,然后将道具传递给它。
  4. 对其进行手动或单元测试。(您需要确保它收到了它应该拥有的道具,并确保它应该如何工作。)
  5. 如果有什么不对劲,请返回您的代码,尝试找出问题所在,进行修复,然后返回步骤no。4。

在TypeScript中,它是相似的,但是更容易,更快捷:

  1. 引导组件功能,定义其类型定义,并实现它。
  2. 如果需要任何外部或复杂数据,请查找它们的接口并重用它们(全部或部分)。
  3. 将组件放到您的应用中,然后将道具传递给它。
  4. 而已。(如果您在调用方和被调用方之间正确地匹配了typedef,则所有内容都应该可以正常工作。现在唯一需要测试的就是组件的实际业务逻辑。)

因此,每当您以TypeScript编写代码时,它不仅更具可读性且不易出错,而且主要是,更易于推理。

3.代码更易于重构

您经常需要重构很多东西,但是由于它们涉及很多东西和文件,因此您太害怕更改它们了。

在TypeScript中,通常只需在IDE中单击“ 重命名符号 ”命令即可重构这些东西。
将“ app”重命名为“ expApp”
在动态类型的语言中,可以帮助您同时重构多个文件的最佳方法是使用RegExp搜索和替换。

在静态类型语言中,不再需要“搜索和替换”。使用诸如“查找所有事件”和“重命名符号”之类的IDE命令,您可以在应用程序中查看给定功能,类或对象接口属性的所有事件。

每当您想要稍微改善构建系统,重命名组件,更改user对象或删除不推荐使用的属性时,您都不必担心会再发生问题。TypeScript将帮助您查找重构位的所有用法,重命名它,并在重构后代码有任何类型不匹配的情况下向您发出编译错误警告。

4.更少的错误

在多年的前端Web开发中,我注意到,只要有一个人坐在我旁边,每当我做错字时都会对我大喊大叫,我可以节省大约50%的错误修复时间。可能为null的值,或者将对象传递到应该为数组的位置。

我很高兴地说,我终于遇到了那个伙伴:它叫做TypeScript。

多亏了它,现在编写无效代码变得更加困难。如果编译成功,您可能会确定它确实有效。

5.更少的样板测试

当您确定将变量正确地传递到所有给定位置时,就无需再对所有变量进行测试了。 与编写简单的样板单元/集成测试不同,您可以将更多的精力放在测试应用程序的业务逻辑上,而不是测试函数参数是否在彼此之间正确传递。 更少的测试意味着更短的时间来开发新功能,以及更小的代码库,从而减少了代码的复杂性,出错率并且易于维护。

6.代码更易于合并

您团队中的新初级开发人员刚刚发布了PR,引入了新代码。乍一看,一切都还不错:代码看起来不错,单元测试在那里,一切都通过了绿色。

您现在可以确定它可以正常工作吗?如果没有适当的单元测试该怎么办?(是的。让我们认识现实中的人们,我们很多人仍然没有写足够的数量。)您会信任公关创作者吗?还是您会花费宝贵的5分钟时间自行运行代码并进行测试?

如果您的工具链中包含TypeScript,它将为您提供另一项保证检查:typedef编译检查。

如果代码看起来不错,就可以进行单元测试,并且整个程序都可以编译,现在您可以确定整个程序可以正常工作。

使用TypeScript可以更轻松地信任其他开发人员。它可能会提高您查看和合并PR的速度。

(反之亦然:由于类型定义,对于新开发人员而言, 无需深入研究或自己运行代码,就更容易看到其他人的代码部分真正在做什么。)

7.帮助开发人员拥有正确的工作流程

用静态类型的语言编写代码时,首先需要考虑将要接收的数据类型,然后考虑要生成的数据类型。通常只有在那之后,您才坐下来进行实际的实现。

许多人会赌命,这是正确的编码工作流程。

例如,无论何时开发算法,都应首先考虑其理论公式,然后加以实施。

或者,无论何时进行TDD,您首先需要考虑代码在现实中的工作方式(它将接收什么数据以及它将产生什么数据),将其编写为测试,然后实施实际代码。

同样适用于TypeScript。它鼓励您在坐下来执行代码的内部实现之前,先考虑一下代码的接口。

TypeScript缺点

1.需要编译步骤

我的一些后端Node.js朋友告诉我,为他们介绍TS只是不值得的,因为在将.ts它们运行在Node上之前,需要对所有文件进行预编译会带来很多麻烦。 虽然可以肯定您可以通过良好的构建和开发设置来处理该问题,但我不能不同意它会为您的Node.js应用程序增加一些开销。 我在前端环境中对此表示不同。如今,每个人都在编译JS。您需要旧版浏览器支持吗?ES7的功能?CSS-in-JS?对于所有这些,您可能已经使用了babel。可以使用Babel编译TypeScript,就像JS的任何其他语法(包括ES7或JSX)一样。

将TypeScript带到您的前端项目中几乎不会给构建设置带来任何开销。(仅在根本不编译JS的情况下,这可能会带来开销,但是这种情况很少发生在前端。)

2.设置有点困难

我可以同意这一点。例如,TypeScript中的Next.js应用程序和Next.js应用程序之间有什么区别?在第二种情况下,您需要使Node.js服务器,webpack和jest测试运行程序能够与TypeScript一起使用。另外,每当添加诸如React,Redux,Styled-Components之类的库时,还需要为其添加typedef,例如npm i @types/styled-components(除非lib中包含TS typedefs文件)。

您需要回答自己的问题是,您多久做一次这样的事情?值得放弃TypeScript的所有优势吗?

摘要

我是说我们所有人都应该突然切换到TypeScript吗?不。例如,在一个现有项目中切换到它肯定是很多工作,并且在这样做之前,应该认真考虑一下。

但是,如果您要创建一个新的前端应用程序(必须随时间进行维护),那么情况就很清楚了。使用TypeScript。老实说,我很想听听在您的下一个前端项目中使用TS的原因是什么。

我只想这样说:通过使用TypeScript,您将获得许多强大的优势,而一开始只需付出很少的精力。 让我们来做TypeScript的人吧

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1

联系我们