检测网站空间容量,校园门户网站建设先进,wordpress论坛模板下载,门户wordpress主题下载来自Lyft的前端工程师Mohsen Azimi介绍了Lyft向TypeScript转型的过程#xff0c;说明JavaScript类型系统的重要性、为什么Lyft选择TypeScript以及他们的一些实践经验。以下内容翻译自作者的博客#xff0c;查看原文TypeScript at Lyft。 在我刚刚成为JavaScript开发者的时候说明JavaScript类型系统的重要性、为什么Lyft选择TypeScript以及他们的一些实践经验。以下内容翻译自作者的博客查看原文TypeScript at Lyft。 在我刚刚成为JavaScript开发者的时候当有人说要给JavaScript加入类型系统我就会问自己为什么要这么做 现在我已经成为一个JavaScript老手我难以想象没有类型系统支持的JavaScript会是怎样的。大型的JavaScript应用需要类型信息来提升扩展性和可维护性Lyft的很多JavaScript项目从Lyft.com网站到我们的内部工具也不例外。当我还是个JavaScript狂热者的时候看着Lyft的团队和代码库在膨胀开始意识到纯粹的JavaScript已经无法支撑起大型的应用了。 但这也并非意味着要扔掉JavaScript。如果能够加入类型系统一切都会变得不一样。类型系统可以减少bug开发者也因此能够更加方便地查看代码。下面我将讲述Lyft为什么选择了TypeScript以及是怎么做到的。 Bug “Uncaught TypeError: Cannot read property foo of undefined”是JavaScript最常见的一个错误。在访问一个未定义undefined的引用对象的属性时就会发生这个错误。Lyft的纯JavaScript项目在生产环境经常会出现这个问题。JavaScript的常见错误还包括拼写错误比如“document.getElementbyId”这类错误在生产环境会引发大问题。 REST API的类型不匹配问题虽然不常见但一旦发生就是个大bug。比如API响应消息里的一个字段从数字类型变成字符串类型会导致JavaScript出现不可预期的行为。 开发效率 浏览大型的JavaScript代码库不仅耗时而且容易让人感到困惑找不到函数的定义或搞不清楚函数可以接收哪些参数都是常有的事。以下列这段代码为例 /**
* Create an input element
* param {string} type
* param {string|boolean} value
* return {HTMLInputElement}
*/
function createInput(type, value) {const el document.createElement(input);el.type type;if (type checkbox) {el.checked value;} else {el.value value;}return el;
} 这个函数根据传入的类型返回一个HTMLInputElement对象如果是复选框类型就把复选框的“checked”属性值设置为传入的值否则的话就创建一个输入框并把输入框的值设置为传入的值。 这里可能会出现bug假设在创建复选框时传入了错误的值比如 const input createInput(checkbox, false) 即使代码注释里写得很清楚仍然无法阻止bug的产生。把字符串“false”赋值给复选框但复选框的状态仍然会是“true”因为字符串“false”会被解析成布尔类型的“true”。 而如果有了类型系统就可以通过重载帮助开发人员写出正确的代码 /**
* Create an input element
*/
function createInput(type: text, value: string): HTMLInputElement;
function createInput(type: checkbox, value: boolean): HTMLInputElement;
function createInput(type, value) {// code
} 类型系统让代码变得更强大通过API级别的语义可以在一开始就把bug扼杀在襁褓里。 类型系统让重构变得更简单开发人员也因此可以放心地做出代码变更。例如当一个函数签名发生变化在调用方代码没有做出相应改动之前是无法通过TypeScript编译的。 强类型的代码之所以更容易进行重构是因为类型检查器可以确保代码变更可以与项目的其他部分兼容。IDE或代码编辑器为类型系统提供了支持。 带有类型信息的模块更容易维护。使用TypeScript开发的模块在一些编辑器里可以显示出API的提示信息。 TypeScript与FlowType的对决 我们有多种JavaScript类型系统可选择 带有JSDoc类型注解的Google Closure编译器 FlowType TypeScript 虽然我们最终选择了TypeScript但做出这个决定也并不是那么容易的。我们的团队分成两个阵营一个倾向于选择FlowType一个倾向于选择TypeScript。 “FlowType就是JavaScript” FlowType被认为“就是JavaScript”或者“带有类型注解的JavaScript”。这种看法有失偏颇。FlowType是一门独立的语言它的语法是JavaScript的超集。它使用了.js作为文件扩展名所以导致了人们的混淆。实际上不管是JSX还是FlowType它们都不是JavaScript。同样TypeScript和ECMAScript也不是。 调用方类型检查 调用方类型检查是FlowType的一个非常受欢迎的特性。比如 function power2(a) {return a * a;
}
power2(string) 这个函数接收一个数字类型的参数如果在调用时传入了一个字符串FlowType会对此作出警告。而TypeScript则会认为“a”是任意类型所以可以通过编译。 这个特性看起来令人印象深刻但我们只要对代码稍作改动这个特性就不管用了。比如 function foo(a) {console.log(a.b)
}
foo({}) 这段代码可以通过FlowType的编译。 React 因为React和FlowType都是由Facebook开源的看似FlowType比TypeScript更适合用在React中。但在Lyft的项目中我们并没有发现把这两者用在React中有什么不同。 流行程度 虽说FlowType和TypeScript看似旗鼓相当但出于对生态系统未来发展的考虑我们需要关注它们的流行程度。选择流行程度较高的那一个可以帮助Lyft吸引到更多的开发人才。 要衡量一个开源项目的流行程度并非易事不过我还是试着努力找出它们之间的对比数据。 StackOverflow上的问题数量FlowType——900多个TypeScript——38,000多个。 GitHub上的问题数量FlowType——1500多个未解决2200个已关闭TypeScript——2400多个未解决11,200个已关闭。 GitHub上的拉取请求FlowType——60多个未解决1,200个已关闭TypeScript——100多个未解决5000多个已关闭。 npm每月下载数量FlowType——290多万次TypeScript——720多万次。 外部类型定义数量FlowType——340多个在GitHub上有43000个“流类型”目录有些库还提供了.flow类型定义TypeScript——3700多个在GitHub上有约25万个package.json里包含了类型定义Facebook的Redux和ImmutableJS也提供了TypeScript类型定义。 我们在内部进行了一个问卷调查与上述的数据一样TypeScript在Lyft内部也很受欢迎。 迁移到TypeScript 我们的项目里有大量的纯JavaScript代码要一下子把它们全部转成TypeScript并非明智的做法。 于是我们选择了增量迁移。我们使用Webpack编译我们的前端应用通过TypeScript-loader可以很轻松地将TypeScript引入到Webpack中。有了TypeScript-loader我们就可以一边使用TypeScript编写新代码一边零碎地更新旧代码。 TypeScript编译器可以对JavaScript文件进行类型检查所以我们就利用了这一特性对已有的JavaScript代码进行类型错误检查。当然这个只对直接被导入到TypeScript中的JavaScript文件有效。不过最新版本2.5的编译器几乎可以直接用于检查独立的JavaScript文件。 推广TypeScript 网上有很多TypeScript的学习资源。TypeScript的官方网站就提供了大量的学习资料方便开发者入门。另外TypeScript的语法是JavaScript的超集所以对于前端开发人员来说非常直观。 lint工具不仅有助于开发者学习TypeScript对写出一致、流畅的代码也很有帮助。lint工具在没有类型系统的情况下有助于减少有问题的代码而在有类型系统的情况下就更是能够起到保护代码的作用所以我们在所有的项目里使用了TSLint。TSLint比一般的lint工具更强大它可以捕捉到一些很意思的问题比如awaiting-noon-promise而这在纯JavaScript的lint工具里是做不到的。 在进行TypeScript培训和往我们的代码库引入TypeScript的过程中我们发现我们的很多JavaScript代码无法直接使用类型。虽然我们因此感到沮丧但这也正好说明了我们的代码写得不好需要进行重构。 Lyft的TypeScript实践 既然引入了TypeScriptLyft的很多新项目就是纯TypeScript的了。以下是一些使用了TypeScript的项目示例。 TypeScript React转换器 React为它的组件提供了基于运行时的类型系统——PropTypes。我们在Lyft的非TypeScript项目里重度使用了PropTypes。 但在TypeScript里已经不需要运行时类型检查了所有的类型检查都发生在编译阶段。于是我们花了一些时间开发了React JavaScript-to-TypeScript转换器。它利用TypeScript编译器将React组件里的PropTypes转成TypeScript接口。这个工具加速了我们采用TypeScript的进程为我们节省了大量的时间。 通用异步组件 我们尝试在服务器端动态渲染加载的组件这个项目完全使用TypeScript开发它也很好地展示了如何利用类型系统写出可共享的代码。 我们的CSS框架与TypeScript集成 在Lyft我们使用了一个叫作Tetris的原子CSS库。原子CSS的核心理念是说重复类名比重复CSS代码的代价更小。原子CSS框架提供了很多小型的CSS类可以通过组合它们来给元素添加样式。在使用Tetris时开发人员需要记住大量CSS类名比如p-a-m用于给方框增加填充空间。 为了提升开发效率我们编写了一个TypeScript文件它把所有的Tetris类名都导出来开发人员可以在他们最喜欢的编辑器里导入这个文件然后就可以使用类名自动完成功能了。 Swagger到TypeScript代码生成 与后端API集成的代码经常会出现bug这是最让人头痛的问题。后端的变更会影响到前端代码又或者有时候前端的代码变更会破坏与后端API的兼容性。 我们的后端API是通过OpenAPISwagger 2.0来描述的我们因此能够规范前端应用的API使用。我们使用Swagger JSON Schema模型为API客户端自动生成TypeScript接口。 原文地址http://www.infoq.com/cn/news/2017/10/TypeScript-practice-Lyft .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
