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

核心提示有些人担心TypeScript是前端工具链的不必要依赖。是吗?跟着我来了解现实是完全相反的。一个“动态类型语言专家”的故事:在我编程生涯的10多年中,我从未喜欢过静态类型的语言。自从2001年开始编程以来,我一直选择动态选择语言:PHP,J

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

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

在我编程生涯的10多年中,我从未喜欢过静态类型的语言。自从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的优势:

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

它接受什么论点?

它返回什么值?

需要什么外部数据?

为了产生返回值,这些参数和外部数据有什么作用?

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

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

console.log(article)在浏览器中放置一个,运行脚本,(也许单击一下UI),然后阅读日志;

查看该函数的使用位置,并从那里跟踪将哪些数据放入所有出现的位置;

向您的同事询问最近是否正在使用此代码(希望他们仍然健在,在线并记住该代码);

假设它article与您所想的一样,只是希望它能起作用。

这听起来对您熟悉吗?

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

2.代码更容易实现

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

引导组件函数,组成其构造函数参数,编写其余代码。

如果它需要任何外部或复杂的数据(如user或articles),请猜测它的外观,将其保存在自己的内存中,并像在代码中那样使用它。

将组件放到您的应用中,然后将道具传递给它。

对其进行手动或单元测试。(您需要确保它收到了它应该拥有的道具,并确保它应该如何工作。)

如果有什么不对劲,请返回您的代码,尝试找出问题所在,进行修复,然后返回步骤no。4。

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

引导组件功能,定义其类型定义,并实现它。

如果需要任何外部或复杂数据,请查找它们的接口并重用它们(全部或部分)。

将组件放到您的应用中,然后将道具传递给它。

而已。(如果您在调用方和被调用方之间正确地匹配了typedef,则所有内容都应该可以正常工作。现在唯一需要测试的就是组件的实际业务逻辑。)

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

3.代码更易于重构

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

在Typescript中,通常只需在IDE中单击“ 重命名符号 ”命令即可重构这些东西。

在动态类型的语言中,可以帮助您同时重构多个文件的最佳方法是使用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的人吧

 
友情链接
鄂ICP备19019357号-22