cookies & webStorage & indexedDB
cookies
- 由来
- cookie设计的初衷是用于维护HTTP状态
- 原理
- 浏览器首先发送一个无状态请求到服务端
- 服务端带上cookie返回
- 浏览器后面的请求都会带上cookie（如果客户端或者服务端对cookie没有操作的话）
- 生成机制
- 服务端生成，在Http Response Header 中 Set-Cookie
- 客户端生成，通过 document.cookie设置
- 缺陷
- cookie大小限制4k
- cookie附在HTTP请求上，如果数据过大，或导致http请求非常大
webStoreage
- loaclStorage
- 以域名为维度，浏览器持久化存储方案
- 大小5Mb
- 同步接口，占用线程的计算
- 使用方法：
- localStorage.setItem(key,value)
- localStorage.getItem(key)
- sessionStorage
- 以域名为维度，浏览器基于会话级的存储方案（页面关闭后或者新开一个窗口之前存储的数据就会获取不到）
- 大小5Mb
- 同步接口，占用线程的计算
- 使用方法：
- sessionStorage.setItem(key,value)
- sessionStorage.getItem(key)
- indexedDB
- 以域名为维度，浏览器大量结构化数据存储方案，运行在浏览器的非关系型数据库
- 不会小于250Mb，支持二进制存储，理论无上限
- 接口异步，支持事务机制（要不成功，要不失败）
数组方法
- every
- 遍历数组的每个元素，每个元素都满足指定的条件时返回true,否则返回false
- some
- 遇到数组中的满足条件的元素就会返回true（后面的元素不在参与运算）,都不满足返回false
- filter
- 遍历数组，提取满足条件的元素，返回满足条件元素的数组
- reduce
- 遍历数组归并，((pre,cur)=>{return pre+cur}, x)，第0次遍历时x赋值给pre。
- reduce(归并方法(pre，cur）, initValue), pre缓存值，cur当前元素的值
- 累加：arr.reduce((pre,cur)=>{return pre + cur}, 0)
- 找最大值：arr.reduce((pre,cur)=>{return Math.max(pre,cur)},)
- 数组去重：arr.reduce((pre,cur)=>{if(pre.indexOf(cur) === -1) {pre.push(cur)} return pre}, [])
- 归类：arr.reduce((preObj,curObj)=>{ const {city} = curObj; if(!preObj[city]){preObj[city]=[]}; preObj[city].push(cur); return preObj; }, {})
- 字符串翻转：Array.from(str).reduce((pre,cur)=>{ return ${cur}${pre} },‘’)
RESTFul - API
- representation state transfer Application Program Interface
- 表示性状态转移接口, API设计规范：
-
- 将一切数据视作资源
-
- 利用 HTTP 请求方式，描述对资源的操作（增、删、改、查）
-
- 通过 HTTP 响应状态码， 描述对资源的操作结果。
- 期望的效果是：
-
- 看url就知道是什么资源
-
- 看 method 知道对资源做了什么操作
-
- 看 Response Code 知道操作是否成功
- Method 规范：
-
- GET 用于读取资源
-
- POST用于创建资源
-
- PUT用于更新资源
-
- Patch 用于局部更新
-
- Delete 用于删除
- 示例：
- 普通 API
- /api/getUser
- /api/createUser
- /api/deleteUser
- RESTFul API
- GET /api/users/:user_id
- POST /api/users
- DELETE /api/users/:user_id
- 好处：
- 有效降低沟通成本
- 前后端解耦更彻底
- 前端业务更灵活
前端内存泄漏
- 内存的生命周期：
- 程序执行都先分配好内存（在js中是隐藏的操作）
- 在内存中进行逻辑读/写
- 垃圾清除，释放/回收内存（在js中是隐藏的操作）
- 内存泄漏是指在程序中已经不在使用的变量，但垃圾回收机制认为还在使用，导致内存无法释放。
- 场景1：意外定义全局变量，不如通过通过this定义变量时，this指向windows时，会导致变量都在windows对象中，即使组件的生命周期到了，定义的这些变量也有可能不会被回收。
- 场景2：console.log，打印一些变量到控制台，比如对象，那这个对象是释放不了的，因为它需要一直显示在控制台
- 场景3：没有控制好的闭包。比如闭包返回的function赋值给一个全局变量，但没有执行，如果这个全局变量没有置为null,那么这个function对象则一直会被GC认为在使用中
- 场景4：DOM泄漏。比如通过document.createElement创建的元素，再被插入到dom中后，删除对应的的父节点，怎创建的元素不在被使用，但是垃圾回收机制认为这些创建的元素还是在被引用。
- 内存的生命周期：
- 普通 API
-
-
-
- every
- loaclStorage