最近参加了几次公司组内的 Code Review, 发现了一些问题。其中一些问题可以通过工具(比如 eslint)解决。 我们就想着通过工具自动化的方式进行解决。 而这些工具中有一些是现成的,比如 魔法数。 大家对魔法数的看法也是莫衷一是。本文通过讲解什么是魔法数,eslint 是怎么检查魔法数的,以及思考为什么eslint 偏爱数字,而不是偏爱字符串来
来深入剖析一下魔法数。
最近参加了几次公司组内的 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 团队也不会花费两年的时间来搞这一个东西。建议大家多读几遍。
这是本系列文章的第三篇,这里我将带你从新的视角来看当前的前端应用,
虽然这其中涉及到的道理很简单,但是这部分知识很少被人看到,更不要说推广和应用了。
这里新的视角指的是我们从进程和线程的角度来思考我们前端应用的运行,从而从更高的层次去审视和优化我们的应用,甚至整个前端生态。
希望你看完之后从思维上也好,工作应用中也好能够有所收获。
前一段时间我分享了几篇关于《数据结构与算法在前端领域的应用》的文章。
文章链接:
这是一个我即将做的一个《数据结构与算法在前端领域的应用》主题演讲的一个主菜。
如果你对这部分内容比较生疏,可以看我的数据结构和算法在前端领域的应用(前菜)
这里我会深入帮助大家如何根据业务抽离出纯粹的模型,从而转化为算法问题,
这是一个我在公司内部做的一个《数据结构与算法在前端领域的应用》主题演讲的一个前菜。
希望通过这个分享让大家认识到其实前端领域也有很多算法的,从而加深前端同学对算法的认识。
3 / 3