主页 · 2

由于在项目中有很多弹窗,但是每次开发声明式弹窗内容的时候,内心总会有一种抵触感,因为在开发弹窗的时候给人一种很强的割裂感,如果你的弹窗内的内容是放在单独的组件内,就会有一种反复横跳的感觉,还要单独去关注维护弹窗显隐的状态,以及一些额外的操作。于是就萌生了要开发一个命令式弹窗组件的想法，在使用体验过后，尽管尤大大是反对命令式这种交互 》 链接，但是我觉得都不是问题，用完真的回不去了。

首先说明一下场景: 项目是一个采用vue3构建的应用,一直工作的好好的,但是今天测试那边突然说有几个页面打不开了,只要一点进去浏览器就会卡死.然后我们前端就在本地查看了下那几个页面,但是奇怪的是本地能运行的好好的,一到线上就拉闸,而且浏览器没有任何报错,这就很复杂了,这类本地无法复现的bug是最伤脑经的,因为某些原因几乎无法本地调试(以后要想个办法).

js在我们的认知中一直是一门纯粹的单线程语言，但是worker线程的出现，让它的单线程特性变得不那么纯粹了~ worker线程是独立于主线程的一个线程，所以即使它遇到大量密集的计算，主线程也不会受影响。这也是我们使用它的一个原因，我们可以把比较繁重的任务交给它来执行，我们只需要等待最后的结果即可。 但是开启一个worker线程，代价也是比较大的（其实几乎任何语言，开启线程代价都是需要考量的，不频繁的创建销毁线程，会有线程池这些东西的存在都是有原因的），因为worker线程有着自己的独立的运行环境，这意味着一个js环境里有的东西，在它的环境里也需要基本具备，可想而知是这是多么巨大的代价。所以，一般我们需要长期运行的任务交给worker线程才是最合适的。

假设我们现在有以下DOM结构，我们现在的需求是要去遍历li标签做一些操作，但是有一个额外条件，我们不需要遍历ol标签下的li标签

在工作中,我们为了避免用户的误操作,以及程序的错误设置带来的过于频繁的执行某些操作,比如数据的增删改操作,比如用户的输入操作等,这些问题除了会影响应用性能问题外,甚至会导致程序出现一些错误.我们通常会使用节流和防抖来解决该类问题,我们通常的做法是使用节流和防抖来增强我们的函数让某些操作减少执行,所以我们今儿使用axios的取消操作来实现接口级防频繁请求.

生成器拥有在一个函数内暂停和恢复代码执行的能力,这里值得一说,我们熟悉的异步解决方案async,await就是基于生成器实现的.

比如我们眼前有一个数组,[1,2,3,4,5],我们可以使用下边的代码中的for循环来轻易的进行循环迭代.

事情是这样的,在工作中由于业务的演进,一个模块有了二级业务,这个任务交到了我,然后我发现一级和二级的视图和业务逻辑很相似,只是存在一些细微的区别;那这样最好了,可以直接复用一级业务的组件,然后我给这个组件定义一些props来做区分是哪一级的业务即可,合理,开干.

这道题目的核心思想理解栈的数据结构

为了解决软件设计中普遍存在的问题,前辈们总结了一些解决方案.而我们熟知的设计模式是前辈们通过经验总结下来的标准或者思路,它经受住了时间的考验;设计模式一词是由埃里希·伽马由建筑设计领域引进计算机世界;