definitely types仓库是怎么产生的?

那是一个下午,QA兄弟想要定制一个富文本编辑器的功能。我说做不了,他说,为什么做不了,于是我给他讲了一个故事

在遥远的以前,每次程序员们想要开发一个功能
都是自己一点点去写出来
时间久了
万千的程序员朋友们发现
他们发现的功能很多都是共用的,重复的
于是有一天,有一个人想
时候可以把我做好的功能通过一个渠道分享给别人使用
这样,更多的人可以用更少的时间开发同样的功能
只需要把别人的代码拿过来,改一下,就好
这种别人的代码,就叫做库
库可以让我们很轻松实现一个非常复杂的功能
但是,同时
由于库都是别人写的,不是自己写的,所以
想要定制化的时候很困难,因为我们并不熟悉别人的库
于是,QA兄弟就理解了,为什么不能短时间定制化

以此类推,请大佬指点一下,DT这个仓库最初是怎么来的,解决了什么问题,我是ts小白,感谢了。

阅读 2.4k
2 个回答

个人理解:

其实这个JS库的历史遗留问题,由于JS是不是强类型的,导致JS定义方法的时候,参数的类型和个数,函数的返回值都是可以不用显式定义的,直接写了就能用。在小项目还好,等到项目越来越大以后会变的越来越难以维护。毕竟这个时候每个方法的具体实现(参数的类型和个数,函数的返回值)都得会看代码才能知道,除非你的注释写的非常非常好(这个不怎么实现)。这个时候就需要一个函数和变量的声明了。借助于TS的快速发展,也就有了现在的index.d.ts文件。

由于历史原因,很多JS包原作者可能都已经不维护了,但是还需要用到,这个时候只能发挥社区的力量,微软发起了这个项目,并且发挥社区的力量,给这些库补充声明文件,统一发布到npm,由于库很多,慢慢的这个仓库就变的越来越大了。很多的JS的历史包也有了自己的声明文件,在开发的时候也方便了很多。

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
logo
Microsoft
子站问答
访问
宣传栏