先大致回顾一下, 相关的,我以前学习的知识点,
- 执行顺序
刚开始接触js的时候, 明白执行顺序非常重要,
同样的语句, 执行顺序更换, 会得出不同的结果.(比如先加后乘, 和先乘后加,结果不同)
又或者直接就会报错(比如, 不能先使用, 后声明)
- 有一种现象叫异步
实际上, 刚开始接触异步的时候, 有点讨厌, 有点不知所措,
因为难度突然上升了一点点.
后来明白, 在js中, 异步这个东西,和事件监听也是有关系的
比如最典型的异步操作是 setTimeout,
在setTimeout,上注册的函数, 会在本次任务内容全部执行完之后,
在下次轮询的时候, 执行(如果时间条件满足)
- 异步相关产生的一些问题
问题1. 执行顺序怎么得到保障?
问题2. 如何获取, 异步返回的值? 因为return 是失效的
当时想了挺久这两个问题(当时, 没有提炼出问题, 只是后来想想, 想的就是这两个问题)
- 回调才是真正的执行顺序!(有段时间)
因为后来我终于理解, 异步操作这个问题, 这个相关的知识是绕不过去的.
比如, 网络请求, 获取数据之后的操作, 只能是一种异步操作.
当时, 学ajax的时候, 传回调函数, 觉得回调函数略显牛逼啊~还有页面交互, 产生的事件, 明显也是一种异步操作.
所以, 当我一定程度上, 熟悉了异步回调函数之后,
我觉得,我应该更换一下,基本思路,
即, 回调才是一般的控制执行顺序的方法,
因为, 理论上来讲, 异步操作, 可用回调函数
同步操作也可用回调函数!
- 回调地狱问题
当时想过, 为何不把一切都用回调函数的方式,进行控制执行顺序?
即, 无论异步还是同步
当时简单写了一下, 我就明白为啥了, 因为回调地狱, 回调层级
一个是, 层级太深, 可读性太差
一个是, 有点难以跟踪? 假设出了个bug,
我想定位一个bug, 如果是正常顺序写的代码, 还是比较容易定位
而如果是一堆回调函数写的代码, 定位起来还是要稍微费力一点?
所以当时也没多想
- promise的学习
其实, promise学习不是很深,
就是跟着老师, 学习一下promise的用法,
以及, 简单模拟了一下promise的封装
说实话, 我觉得模拟promise的过程,
对我的js理解是一次比较大的提升
当时, 通过阅读代码, 我能基本理解, 这个代码能够实现promise的功能
但当时, 我实在是, 不理解, 第一个想到要这么写的人,
他到底是怎么想到的? 有点太妙了!
promise解决的就是一个异步操作, 回调地狱的问题,
即, 把回调层级降低, 视觉上, 以及思维上, 都搞成了一个线性的感觉.
- 学习node.js里的eventEmitter模拟代码
百度搜索的第二个链接
写得通俗易懂~
其实, 在模拟promise的时候, 我就大概明白什么叫观察者模式,
即, 发布订阅模式
(实际上, 之前的课程里也学过设计模式相关的内容, 不过当时自己有点太菜)
在看这个event 代码
我就对观察者模式理解的稍微更深了一点.
以至于, 我觉得, 这才是使用回调函数的正确姿势!
- eventEmitter的模拟和promise的模拟的区别
实际上他俩的核心非常相似
都是观察者模式,
区别是, 触发方式不同, 且触发类型不同
两个都有一个event对象
接收一个type字符, 创建一个event[type]数组
该数组, type表示事件类型, 数组中, 存放, 绑定的函数
弄出一个接口, 来放入 给event[type]中, 函数
弄出一个接口, 来把event[type]中的函数给触发
eventEmitter 和 promise的最大区别是
- eventEmitter中, type是自定义的, 你可以随意定, 并随意触发
而promise中, type是限定的, 只有reject, resolve两个类型, 只能触发这两个- eventEmitter中, 没有强调链式异步调用, 而promise强调了链式异步调用
即, 被触发的函数, 也有可能会发起一个异步操作,
在promise中, 可以通过new Promise的方式, 继续注册异步函数, 比较方便
而在eventEmitter似乎没有
- 我真正想说的是, 我想到一个想法
上面提到, 使用事件触发方式时, 有可能会出现不知道谁触发的问题.
我在想, 是否可以借鉴路径的概念,
每次通过事件触发时, 在设定的路径变量中, 添加一个标识?
然后, 我们就可以愉快的, 把所有同步的顺序给干掉,
用全异步的方式, 控制顺序?
- 晚上, 我得试着写一写,, 说不定有用?
网友评论