暂时未有相关云产品技术能力~
大前端架构师,10年工作经验,简书/掘金思否优质作者,《JavaScript 核心进阶》《React 知命境》作者,目前自由职业
作为一名光荣而高大上的前端开发工程师,最痛苦的事情是什么?多年的搬砖经验告诉我,那一定是: 做兼容 故事的猪脚就是首图中这破烂货。要怎么形容他呢? 吃苦耐劳! 都摔成这样了,还坚持服役,内心绝望的同时,还必须流露出一丝钦佩之意 操作系统android 5 这台设备由我们老板亲自小心翼翼的交到我们测试大当家手中,千叮万嘱一定要照顾好他,我们又怎敢怠慢 ~
利用chrome开发者工具中的断点调试,我们能够一步步观察JavaScript的执行过程,直观感知函数调用栈、作用域链、变量对象、闭包、this等关键信息的变化。因此,断点调试对于快速定位代码错误,以及快速了解代码的执行过程有着非常重要的作用,这也是我们前端开发必不可少的一个高级技能。 当然如果你对JavaScript的基础概念(执行上下文,变量对象,闭包,this等)了解还不够的话,想要透彻掌握断点调试可能会有一些困难。好在前面几篇文章中,我都对这些概念进行了详细的概述,因此要掌握这个技能,对大家来说,应该是比较轻松的。
这个时候,我们思考一个问题,当我们重复调用summation(100)时,函数内部的循环计算是不是有点冗余?因为传入的参数一样,得到的结果必定也是一样,因此如果传入的参数一致,是不是可以不用再重复计算直接用上次的计算结果返回呢? 当然可以,利用闭包能够实现我们的目的。
在函数式组件中,useRef 是一个返回可变引用对象的函数。该对象.current属性的初始值为useRef传入的参数initialVale。 返回的对象将在组件整个生命周期中持续存在。 const ref = useRef(initialValue); 通常情况下,useRef有两种用途, •访问DOM节点,或者React元素 •保持可变变量
这是一个需要在实践中,不断去总结,优化才能获得的技能。 首先,将一个复杂的页面逻辑进行拆分的目的,一定是为了可读性和可维护性。如果你的组件拆分违背了这两个原则,那么拆分就有问题。 本来我想根据我自己的经验,将组件分为基础组件,工具组件,容器组件,页面组件等大类,但是强行引入这些概念并不利于学习,还是建议大家自己在实践过程中去总结适合自己的拆分思维。 不过,有一些原则可以分享给大家
在context这个高级API出来之前,数据流向只能自上而下,从父组件一层一层的往下传递。如上图左。 如果仅仅只支持这样的方式,在实践中会遇到很多麻烦。 例如一个数据要传到使用它的组件,中间还要经历3个组件。我们就不得不在这三个中间组件中处理该数据的传递逻辑。但其实对于这三个组件而言,该数据毫无用处。 context的出现,就是为了解决这样的痛点。context能够让数据直达需要它的那一个子组件。如上图右
我认识很多专业的前端小伙伴,我知道大家都能够在信息爆炸的碎片化时代,找到海量的 JavaScript 知识,可是找到它们,并不等于学会它们。对于很多人来说,如何掌握好 JavaScript 始终是一个困扰。即使看了多本名书,具备多年工作经验,可依然学不好它,甚至在学习了多年之后,对于基础知识存在许多盲区。
我们在学习JavaScript的过程中,由于对一些概念理解得不是很清楚,但是又想要通过一些方式把它记下来,于是就很容易草率的给这些概念定下一些方便自己记忆的有偏差的结论。 危害比较大的是,有的不准确的结论在网上还广为流传。 比如对于this指向的理解中,有这样一种说法:谁调用它,this就指向谁。在我刚开始学习this的时候,我非常相信这句话。因为在一些情况下,这样理解也还算说得通。可是我常常会在开发中遇到一些不一样的情况,一个由于this的错误调用,
值得高兴的是,很多朋友在阅读了我的文章之后确实对闭包有了更加深刻的了解,并准确的给出了好几种写法。大家能够认真的阅读我的文章并且一个例子一个例子的上手练习,这种认可对我而言真的非常感动。 但是也有一些基础稍差的朋友在阅读了之后,对于这题的理解仍然感到困惑,因此应一些读者老爷的要求,借此文章专门对setTimeout进行一个相关的知识分享,希望大家读完之后都能够有新的收获。
初学JavaScript时,我在闭包上,走了很多弯路。而这次重新回过头来对基础知识进行梳理,要讲清楚闭包,也是一个非常大的挑战。 闭包有多重要?如果你是初入前端的朋友,我没有办法直观的告诉你闭包在实际开发中的无处不在,但是我可以告诉你,前端面试,必问闭包。面试官们常常用对闭包的了解程度来判定面试者的基础水平,保守估计,10个前端面试者,至少5个都死在闭包上。
作用域与作用域链本应该是一个非常简单的概念。可是在近两年多的留言中,我发现这些概念反而成为了大多数人想不明白的点,而感到困惑的原因在于,别的文章里,常常会提到词法作用域,词法分析等概念,到底是什么东西?好像跟我说的有一点不一样,但又不知道哪里不对? 为了避免接下来更多的同学造成同样的困扰,我写了一篇名为(v8引擎是如何工作的)文章,为大家分析JS的工作原理。后续会整理进入基础进阶系列文章。大家可以随时阅读。
Reducer函数接收两个参数,第一个参数是当前的最新状态值,第二参数则用于告诉Reducer当前执行了什么操作。Reducer会根据不同的操作执行不同的逻辑去修改state。 因此我们称第二个参数为Action。 在这个简单的案例中,Action被我们定义成为一个字符串,reducer内部会根据不同的字符串,执行不同的修改状态逻辑。
暂时先不管这个例子,我们先引入一个JavaScript中最基础,但同时也是最重要的概念:执行上下文(Execution Context) 每次当控制器转到可执行代码的时候,就会进入一个执行上下文。执行上下文可以理解为当前代码的执行环境,它会形成一个作用域。JavaScript中的运行环境大概包括三种情况。 •全局环境:JavaScript代码运行起来会首先进入该环境
因为JavaScript具有自动垃圾回收机制,所以对于前端开发来说,内存空间并不是一个经常被提及的概念,很容易被大家忽视。特别是很多不是计算机专业的朋友在进入到前端之后,会对内存空间的认知比较模糊,甚至有些人干脆就是一无所知。 当然也包括我自己。 在很长一段时间里认为内存空间的概念在JS的学习中并不是那么重要。可当我回过头来重新整理JS基础时,发现由于对它的模糊认知,导致了许多知识理解得并不明白。比如最基本的引用数据类型和引用传递到底是怎么回事儿?浅复制与深复制有什么不同?闭包到底是什么?
今天Spenser在公众号里说,今年许多公司都在裁员。市场上供大于求,但是,好多企业还是招不到人。真正的人才,市面上太稀缺了。这句话真的深有体会。我们公司想要招一个Java的高级开发,招了一个多月都没找到满意的。真的痛苦。 出现这种局面,两极分化就会日渐严重。就以前端行业来看,厉害的人,会越来越难找,也会越来越值钱。而普通的人,混口饭吃都不容易。 还是那句话说得对,外面的世界很精彩,可精彩是属于真正厉害的人
在上一篇文章中已经知道,当调用一个函数时(激活),一个新的执行上下文就会被创建。一个执行上下文的生命周期可以分为两个阶段。 •创建阶段 在这个阶段中,执行上下文会分别创建变量对象,建立作用域链,以及确定this指向。 •代码执行阶段 创建完成之后,就会开始执行代码,会完成变量赋值,函数引用,以及执行其他代码。
在实践中,我们常常会遇到逻辑相同的功能片段。对于这样的场景,更省力的方式是,将这些功能片段封装成为一个单独函数来使用。 例如,比较两个数组是否相等,可以封装一个equal方法,来处理这个通用逻辑。 假设我们想要实现如下功能:比较左右两侧的数组是否相同。中间红色字为实时比较结果。每个数组都提供两个操作数组的按钮,点击一下,分别往原数组中添加数字1或者数字2 。
在function组件中,每当DOM完成一次渲染,都会有对应的副作用执行,useEffect用于提供自定义的执行内容,它的第一个参数(作为函数传入)就是自定义的执行内容。为了避免反复执行,传入第二个参数(由监听值组成的数组)作为比较(浅比较)变化的依赖,比较之后值都保持不变时,副作用逻辑就不再执行。 如果读懂了,顺手给我点个赞,然后那么这篇文章到这里就可以完结了。
我们可以在父组件中定义state,并通过props的方式传递到子组件。如果子组件想要修改父组件传递而来的状态,则只能给父组件发送消息,由父组件改变,再重新传递给子组件。 在React中,state与props的改变,都会引发组件重新渲染。如果是父组件的变化,则父组件下所有子组件都会重新渲染。
曾经我去找工作面试的时候,我最讨厌别人问我闭包,因为我说不清楚。现在我面试别人了,却又最爱问闭包,因为闭包真的能直接的检验你对JS的理解深度。可能够回答上来的人真的很少。 两年以来我面试过估计200多人,其中技术能力最强的是阿里P6的一个胖胖的哥们儿,这里简称PP。PP的JS基础很扎实,对React的理解比较深刻,其他问题上我们聊得很开心。可即使是这样的高手,在闭包的问题上也有些犯难,没有第一时间回答出来我想要的答案。
过去大半年里,我将React Hooks应用到了许多大型项目,其中5个全新重构,其他项目由于时间关系少量使用。 这些项目包括 •React Native•基于ant-design-pro重构的中后台应用•基于React,专注于小程序开发的Taro应用•以create-react-app为基础,自主构建的web应用•基于beidou框架的改造的同构应用等
现在是2019年11月2日,从刚开始写这系列文章到现在已经过去两年多时间了。两年以来,阅读过这系列文章的朋友远超我的想象。在简书这样一个鲜为人知的平台上,阅读量超过10W+。技术文章能够有这样的热度,非常非常难,因此内心很有成就感,每当看到大家留言对这系列文章的肯定与鼓励,心中都非常开心。 偶尔有朋友留言建议我说,这系列文章可以出书。其实两年以前就出了。