lucifer

泛型是 TypeScript(以下简称 TS) 比较高级的功能之一,理解起来也比较困难。泛型应用场景非常广泛,很多地方都能看到它的影子。平时我们阅读开源 TS 项目源码,或者在自己的 TS 项目中使用一些第三方库(比如 React)的时候,经常会看到各种泛型定义。如果你不是特别了解泛型,那么你很可能不仅不会用,不会实现,甚至看不懂这是在干什么。

相信大家都经历过,看到过,或者正在写一些应用,这些应用充斥着各种重复类型定义, any 类型层出不穷,鼠标移到变量上面的提示只有 any,不要说类型操作了,类型能写对都是个问题。我也经历过这样的阶段,那个时候我对 TS 还比较陌生。

随着在 TS 方面学习的深入,越来越认识到 真正的 TS 高手都是在玩类型,对类型进行各种运算生成新的类型。这也好理解,毕竟 TS 提供的其实就是类型系统。你去看那些 TS 高手的代码,会各种花式使用泛型。 可以说泛型是一道坎,只有真正掌握它,你才知道原来 TS 还可以这么玩。怪不得面试的时候大家都愿意问泛型,尽管面试官很可能也不怎么懂。

只有理解事物的内在逻辑,才算真正掌握了,不然永远只是皮毛,不得其法。 本文就带你走进泛型,带你从另一个角度看看究竟什么是泛型,为什么要有它,它给 TS 带来了什么样的不同。

注意:不同语言泛型略有不同,知识迁移虽然可以,但是不能生搬硬套,本文所讲的泛型都指的是 TS 下的泛型。

除了调试,处理异常或许是程序员编程时间占比最高的了。我们天天和各种异常打交道,就好像我们天天和 Bug 打交道一样。因此正确认识异常,并作出合适的异常处理就显得很重要了。

我们先尝试抛开前端这个限定条件,来看下更广泛意义上程序的报错以及异常处理。不管是什么语言,都会有异常的发生。而我们程序员要做的就是正确识别程序中的各种异常,并针对其做相应的异常处理

然而,很多人对异常的处理方式是事后修补,即某个异常发生的时候,增加对应的条件判断,这真的是一种非常低效的开发方式,非常不推荐大家这么做。那么究竟如何正确处理异常呢?由于不同语言有不同的特性,因此异常处理方式也不尽相同。但是异常处理的思维框架一定是一致的。本文就前端异常进行详细阐述,但是读者也可以稍加修改延伸到其他各个领域。

本文讨论的异常指的是软件异常,而非硬件异常。

最近公司在推行单元测试,但是一些同事对于单元测试只是了解,甚至不怎么了解。因此推动单元测试的阻碍是有的,这种阻碍除了人的层面,还有基础设施的层面。希望通过本文,一方面加深大家对前端测试最佳实践的认知,另一方面可以作为手册,在日常开发中做参考。本文也会不断更新,期待你的参与。

如果大家对前端测试不太清楚,可以先看下文末我写的科普短文。如果你已经对前端测试有所了解,并且希望对前端测试有更深入的了解,以及对如何写出更好的单元测试有兴趣的话,那就让我们开始吧。

最近参加了几次公司组内的 Code Review, 发现了一些问题。其中一些问题可以通过工具(比如 eslint)解决。 我们就想着通过工具自动化的方式进行解决。 而这些工具中有一些是现成的,比如 魔法数。 大家对魔法数的看法也是莫衷一是。本文通过讲解什么是魔法数,eslint 是怎么检查魔法数的,以及思考为什么eslint 偏爱数字,而不是偏爱字符串来 来深入剖析一下魔法数。

前端目前比较主流的框架有react,vuejs,angular等。 我们通常去搭建组件库的时候都是基于某一种框架去搭建,比如ant-design是基于react搭建的UI组件库,而elementUI则是基于vuejs搭建的组件库。

虽然目前社区有相关工具,提供框架之间的转化服务,比如讲vuejs组件转化为react组件。但是毕竟是不同的框架,有不同的标准。因此框架api发生变动,那么你就需要重写转化逻辑,显然是不灵活的,因此我们暂不讨论这种情况。作为公司而言,就需要为不同的框架写不同的组件库,尽管逻辑都是一样的。

另外如果框架升级,比如从1.x升级到2.x,那么对应组件库就需要升级,如果公司的组件库有很多(vuejs,react,angular等),那么这种升级的概率就会更大。

回想四年前我刚入行的时候,那时候很多人对于前端的看法是“切图,画页面,有个编辑器+浏览器就能干,门槛低”,现在已经完全不是那样了,可以说现在的前端这个职业的门槛虽然还是没怎么变,但是整个行业的门槛提升了,换句话说就是整个行业对于前端这个职位要求更高了,对于前端小白的需求量降低,对于高级前端的需求量还在上升,甚至是供小于求的局面。从市场经济学角度上讲你只有进入到高级级别,才能真正吃到行业的红利。 因此想要入行的朋友要先想清楚,不要头脑发热,如果你想清楚了,那么请继续往下看。
说实话,现在的前端大环境对初学者来说实在有点不友好,学习资料鱼龙混杂,良莠不齐,有质量很高的学习资料,也有谬论,前后不一,观点错误,或者讲述不清晰的。 更可怕的是质量低下的文章有时候更受欢迎,因此需要大家有很好的甄别能力,但这对于初学者来说实在有些困难,我在这里就来谈一下 初学者如何少走弯路,并且系统性地学习前端

实际上浏览器的事件循环标准是由 HTML 标准规定的,具体来说就是由whatwg规定的,具体内容可以参考event-loops in browser。而NodeJS中事件循环其实也略有不同,具体可以参考event-loops in nodejs

我们在讲解事件模型的时候,多次提到了事件循环。 事件指的是其所处理的对象就是事件本身,每一个浏览器都至少有一个事件循环,一个事件循环至少有一个任务队列。循环指的是其永远处于一个“无限循环”中。不断将注册的回调函数推入到执行栈。

那么事件循环究竟是用来做什么的?浏览器的事件循环和NodeJS的事件循环有什么不同?让我们从零开始,一步一步探究背后的原因。

前一段时间我分享了几篇关于《数据结构与算法在前端领域的应用》的文章。

文章链接:

这一次我们顺着前面的内容,讲一些经典的数据结构与算法,本期我们来讲一下时下比较火热的React fiber

这部分内容相对比较硬核和难以消化,否则 React 团队也不会花费两年的时间来搞这一个东西。建议大家多读几遍。

这是本系列文章的第三篇,这里我将带你从新的视角来看当前的前端应用,
虽然这其中涉及到的道理很简单,但是这部分知识很少被人看到,更不要说推广和应用了。

这里新的视角指的是我们从进程和线程的角度来思考我们前端应用的运行,从而从更高的层次去审视和优化我们的应用,甚至整个前端生态。

希望你看完之后从思维上也好,工作应用中也好能够有所收获。

前一段时间我分享了几篇关于《数据结构与算法在前端领域的应用》的文章。

文章链接:

这是一个我即将做的一个《数据结构与算法在前端领域的应用》主题演讲的一个主菜。
如果你对这部分内容比较生疏,可以看我的数据结构和算法在前端领域的应用(前菜)

这里我会深入帮助大家如何根据业务抽离出纯粹的模型,从而转化为算法问题,



博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议

本站使用 Material X 作为主题 , 总访问量为 次 。
载入天数...载入时分秒...