我们正在遵循airbnb
eslint 指南,他们在其中说建议不要使用生成器
11.2 暂时不要使用生成器。
为什么?它们不能很好地转换为 ES5。
我似乎无法找到任何解释,解释它们的意思是翻译不好(不仅在本文档中,而且在 Google 上)。我们正在使用 babel,并且有 polyfills 可以做到这一点。有什么我想念的吗?
我们正在遵循airbnb
eslint 指南,他们在其中说建议不要使用生成器
11.2 暂时不要使用生成器。
为什么?它们不能很好地转换为 ES5。
我似乎无法找到任何解释,解释它们的意思是翻译不好(不仅在本文档中,而且在 Google 上)。我们正在使用 babel,并且有 polyfills 可以做到这一点。有什么我想念的吗?
他们完全是错误的(或者文档严重过时)。转译器从生成器和异步函数创建基于闭包的状态机。他们不是很好,但工作得很快。唯一的缺点是更难调试(即使使用源映射)。
另一方面,在某些情况下,不使用生成器会导致尴尬的变通方法,生成器会提供干净的解决方案。始终首先编写代码以保持清晰。
编辑
我们开发人员在现实生活中了解到,一些编程挑战最好用状态机来解决。生成器和异步函数为您提供了一个强大的工具来表达大多数状态机。
这就是语言的演变方式:我们发现一个重复出现的编程问题有一个解决方案,因此人们创建了一种具有新语法的新编程语言,以便为该问题提供更短的解决方案。这就是我们获得基本数据结构、函数、闭包、类、一等函数、GC、RTTI、反射等的方式......今天,您可以选择在项目中使用哪种语言。您可以直接编写机器代码,或使用一些高级托管语言。争论通常是关于执行速度(汇编应该更快吧?)、可移植性和所用语言语法的学习曲线(为什么我要学习 lambdas、yield 和 async/await,而我总是能够解决任何问题)不使用其中任何一个问题?). 我个人更喜欢使用表达性语言,并且我相信高级/托管程序不会永远比原生程序慢。
因此,让我强调一下不使用生成器会造成什么损失:您最终会编写相同的一百行状态机(可能伪装成对象和函数的集合),这些状态机可以使用合理且熟悉的语法从短程序生成。