当前位置:首页 >时尚 >前端框架Svelte放弃TS,如何使用纯JS实现类型检查? 前端框架Svelte放弃TS

前端框架Svelte放弃TS,如何使用纯JS实现类型检查? 前端框架Svelte放弃TS

2024-06-30 07:59:58 [百科] 来源:避面尹邢网

前端框架Svelte放弃TS,前端如何使用纯JS实现类型检查?

作者:CUGGZ 开发 前端 最终 JSDoc 会取代 TypeScript 进行类型检查吗?我认为是框架不会的。TypeScript 非常适合应用开发,放弃而且它正在不断改进。何使不过对于库开发来说,用纯使用纯 JavaScript 和 JSDoc 注释似乎是实现更好的选择。

近日,类型前端框架 Svelte 的检查创建者 Rich Harris 提出要将 Svelte 从 TypeScript 切换到使用 JSDoc 的 JavaScript。这种转变得到了 Svelte 团队的前端大力支持,他们决定在 Svelte 4 代码库中从 TypeScript 迁移到 JavaScript JSDoc。框架而这个决定引起了开发社区的放弃惊讶和怀疑。

那为什么要从 TypeScript 转向 JavaScript JSDoc 呢?这是何使否是技术的倒退?JSDoc 又是什么?它有什么特点?如何使用?下面将详细介绍!

前端框架Svelte放弃TS,如何使用纯JS实现类型检查? 前端框架Svelte放弃TS

图片

前端框架Svelte放弃TS,如何使用纯JS实现类型检查? 前端框架Svelte放弃TS

Svelte 是一个现代的 JavaScript 框架,它允许开发者以声明式的实现方式写组件,并在构建时将这些组件转化为高效、类型优化的纯 JavaScript 代码。相比于其他框架,Svelte 更加轻巧,在性能和体验方面也有着不俗的表现。使用 Svelte 可以帮助开发人员更快速地构建交互式应用程序,同时还可以减少运行时性能负担和包大小。

前端框架Svelte放弃TS,如何使用纯JS实现类型检查? 前端框架Svelte放弃TS

为什么转向JSDoc?

Svelte 团队认为,尽管类型系统非常棒,但作为一种语言,TypeScript有些“麻烦”。主要问题在于使用 TypeScript 会带来额外的工具。例如,如果在 TypeScript 中构建一个库,并在另一个项目中使用该库,就不能只修改代码库还需要重新构建代码,这增加了不必要的复杂性。

图片

为了规避这些问题,Svelte 团队决定使用 JavaScript 和 JSDoc 注释来实现类型安全。这种方法提供了所有类型安全的好处,而没有与 TypeScript 相关的缺点。SvelteKit 代码库已经采用了这种方法,团队计划对 Svelte 4 进行同样的处理。不过,作为Svelte的用户,这不会影响在Svelte 中使用 TypeScript 的能力,从Svelte导出的函数仍将具有习以为常的所有 TypeScript 优点(类型检查、智能感知、内部文档等)。

什么是 JSDoc?

很多开发人员之所以选择 TypeScript,是因为强类型可以减少错误,并通过代码完成和弹出帮助等功能改善代码编辑器中的开发体验。而主要是 API 文档工具的 JSDoc 也可以用于类型检查。

JSDoc 是一种用于在 JavaScript 代码中编写文档和类型注释的标记语言,它使用类似于JavaDoc 的注释语法。通过在代码中添加特定的注释标记,可以生成文档,提高代码的可读性和可维护性。JSDoc不仅可以描述函数的参数和返回值类型,还可以用来描述类、对象、模块和命名空间等各种 JavaScript 实体的属性和方法。

图片

那相较于 TypeScript,JSDoc 有什么优点呢?

  • 与语言无关:JSDoc只是一种在类似于JavaScript的语言中编写文档和类型注释的方式,使其更加灵活。可以在各种环境中使用它,而TypeScript可能不太适合某些环境。
  • 易于集成:由于 JSDoc 只是基于注释的系统,因此不需要更改代码或工具。可以开始向现有的JavaScript代码库添加JSDoc注释,而无需太多麻烦。
  • 学习曲线较低:与TypeScript相比,JSDoc非常直接明了,学习起来更容易,TypeScript可能需要开发人员学习新的语法和类型概念。
  • 文档受益:JSDoc为编写代码文档提供了一种一致的方法。这使得其他开发人员更容易理解代码库,并有助于生成文档。
  • 渐进式采用:可以逐渐向代码库添加JSDoc,这样可以逐步将类型检查和文档引入项目,而无需完全采用TypeScript。
  • 无需构建步骤:JSDoc不像TypeScript那样需要构建步骤进行类型检查和转译。

如何使用 JSDoc?

使用 JSDoc 不需要任何前置操作。只需要在 JavaScript 代码中添加 JSDoc 注释即可。JSDoc 注释以“/**”开头,以“*/”结尾,位于要描述的代码块之前。可以通过以下方式来将 JSDoc 用于类型检查。

  1. 在每个变量声明、函数声明等之前添加 JSDoc 注释,描述它们的类型和用途。例如:
/** * @type { number} */const num = 42;/** * 两数之和 * @param { number} x * @param { number} y * @returns { number} 返回值 */function add(x, y) {   return x + y;}
  1. 使用 JSDoc 注释来描述自定义类型和接口。例如:
/** * @typedef { Object} Person * @property { string} name - The person's name. * @property { number} age - The person's age in years. *//** * @interface Shape * @property { number} x * @property { number} y * @property { number} width * @property { number} height */
  1. 可以使用文档生成工具(如 JSDoc-to-HTML)将 JSDoc 注释自动生成为文档。例如,在使用 JSDoc 注释编写完整的库或应用后,可以使用 JSDoc-to-HTML 工具将其转换为漂亮的文档。

JSDoc 以@标记名称的形式提供了很多标记,常用的包括:

  • @param:用于描述函数的参数。允许指定参数名称、类型和描述信息。
  • @returns:用于描述函数返回值的类型和描述信息。
  • @typedef:用于定义自定义类型或对象。允许指定类型名称、属性列表和描述信息。
  • @property:用于描述对象的属性。允许指定属性名称、类型和描述信息。
  • @callback:用于描述回调函数的参数和返回值类型。
  • @class:用于描述一个类。允许指定类的名称、属性、方法和描述信息。
  • @constructor:用于描述一个构造函数。允许指定构造函数的参数、返回值和描述信息。
  • @enum:用于定义一个枚举类型。允许指定枚举名称、属性列表和描述信息。
  • @namespace:用于描述命名空间。允许指定命名空间的名称和描述信息。
  • @readonly:用于指定只读属性或参数。
  • @private:用于指定私有属性或方法。
  • @public:用于指定公共属性或方法。
  • @protected:用于指定受保护的属性或方法。
  • @throws:用于描述函数可能引发的异常。允许指定异常类型和描述信息。

这些标记只是 JSDoc 提供的许多标记中的一部分。JSDoc 还提供了许多其他标记,如 @augments、@example、@ignore、@link、@since 等。通过使用这些标记,可以更好地记录和描述 JavaScript 代码。

需要注意,尽管可以使用 JSDoc 代替 TypeScript 进行类型检查,但它并不像 TypeScript 一样强制执行类型检查。如果在 JSDoc 注释中错误地描述了类型,或者没有提供足够的类型信息,将无法得到类型检查的保护,这可能会导致运行时错误。因此,在使用 JSDoc 进行类型检查时,需要格外小心,并尽可能详细地记录变量和参数的类型。

小结

最终 JSDoc 会取代 TypeScript 进行类型检查吗?我认为是不会的。TypeScript 非常适合应用开发,而且它正在不断改进。不过对于库开发来说,使用纯 JavaScript 和 JSDoc 注释似乎是更好的选择。

绝大多数开发人员不是在构建库,而是在构建应用。因此,TypeScript 将保持主要的类型检查方式,直到 JavaScript 实现原生类型检查为止。

选择 TypeScript 还是带有 JSDoc 的 JavaScript 取决于开发团队或开发人员的需求和偏好。对于库作者来说,JavaScript 和 JSDoc 的简单性和灵活性特别有吸引力的。对于已经具有构建中的应用,TypeScript 仍然可能是首选。

责任编辑:武晓燕 来源: 前端充电宝 TypeScriptJSDoc开发

(责任编辑:综合)

    推荐文章
    热点阅读