day32
一、review购物车思路
1.大致思路
+ 通过数据控制界面（数据驱动视图） + H5自定义属性 => data-属性名 => ele.dataset.id
2.渲染功能
+ render()
=> 根据localStorage里面是否有数据，进行判断，做不同的数据渲染的处理
=> 如果没有数据，就给用户一个提示信息，展示到表格里面 if(!this.list.length){}
=> 如果有数据，把数据取出来，渲染购物车界面
=> 渲染了尾部的数据
=> 给要操作的标记绑定了自定义属性
=> 给单选按钮绑定checked属性 ${item.is_select && 'checked'}
=> 使用every()方法判断数据里面is_select是否都为true，如果为true，就把状态赋值给全选复选框 _state
=> 判断当前的数据is_select是否为true，把商品数量和商品价格进行处理 totalPirce += item.cart_num * item.price
=> ...
3.事件绑定功能
+ bindEvent()
=> 给外层的元素进行事件的绑定 addEventListener()
=> 做事件委派
=> 全选
=> 判断点击是否为全选按钮 if(t.className === 'allSelect'){}
=> 获取全选复选框的状态 state = t.checked
=> 遍历this.list数据，把state赋值给所有的数据里面的is_select属性，这个属性默认是false
=> 调用渲染函数 this.render()
=> 单选
=> 获取自定义的id
=> 使用find()查找到当前的数据
=> 把数据的goods.is_select进行取反操作 goods.is_select = !goods.is_select
=> 调用渲染函数 this.render()
=> 数量增加
=> 获取自定义的id
=> 使用find()查找到当前的数据
=> 判断是否到达库存数据
=> 把数据里面的cart_num自增 goods.cart_num++ || goods.cart_num += 1
=> 调用渲染函数 this.render()
=> 数量减少
=> 获取自定义的id
=> 使用find()查找到当前的数据
=> 判断是否为1，如果为1就禁止
=> 把数据里面的cart_num自增 goods.cart_num-- || goods.cart_num -= 1
=> 调用渲染函数 this.render()
=> 单个删除
=> 获取自定义的id
=> 使用findIndex()查找到当前的数据的下标
=> 使用splice()方法进行删除
=> 调用渲染函数 this.render()
=> 选中删除
=> 使用filter()方法进行过滤
=> 把数据中is_select为false的筛选出来
=> 把筛选出来的数组进行赋值 this.list = newList.filter()
=> 调用渲染函数 this.render()
=> 结算
=> 通过查询字符串传递价格去结算页面
=> 通过sessionStorage进行临时存储
二、swiper
名词 + 插件 => 指的是某个单一的功能，把这种称之为插件 例如：tools.js + 类库 => 指的是是一类（同类型）的功能，把所有的情况都考虑和列举到了 例如：swiper + 框架 => 可以做所有事情，框架里面会配套存在很多的差距或者类库
三、cookie
1.三次握手
第一次握手
-
客户端发了个连接请求消息到服务端
-
服务端收到信息后知道自己与客户端是可以连接成功的，但此时客户端并不知道服务端是否已经接收到了它的请求，所以服务端接收到消息后得应答，
第二次握手
-
客户端得到服务端的反馈后，才确定自己与服务端是可以连接上的，这就是第二次握手
-
两次握手已经建立连接，为什么还需要第三个握手呢？
-
例如：客户端发出去的第一个连接请求由于某些原因在网络节点中滞留了导致延迟，直到连接释放的某个时间点才到达服务端，这是一个早已失效的报文，但是此时服务端仍然认为这是客户端的建立连接请求第一次握手，于是服务端回应了客户端，第二次握手。
第三次握手
-
如果只有两次握手，那么到这里，连接就建立了，但是此时客户端并没有任何数据要发送，而服务端还在傻傻的等候佳音，造成很大的资源浪费。所以需要第三次握手，只有客户端再次回应一下，就可以避免这种情况。
-
所以说，第三次握手是为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误。
2.HTTP协议（无状态的，多次请求之间没有相关性）
①General：请求综合信息 Response Headers：响应头信息 Request Headers：请求头信息 Payload：载荷:请求参数 Preview：预览信息 Response：后端响应信息 Cookies：存储信息，如果本地存在cookie信息，那么发送请求的时候，默认会把cookie 携带到服务器
HTTP请求由状态行、请求头、请求正文三部分组成： 状态行：包括请求方式Method、资源路径URL、协议版本Version； 请求头：包括一些访问的域名、用户代理、Cookie等信息； 请求正文：就是HTTP请求的数据。
②cookie的特点：
-
cookie中的数据 可以被同一个网站的页面所共享
-
不同浏览器的cookie 不能共享
-
cookie的数据存储在浏览器中，每次请求服务器，在请求报文中携带cookie的数据，发送给服务器
-
服务器端无法直接操作cookie，是通过在服务器端设置响应头的的方式，通知浏览器对cookie进行设置
-
cookie中的数据有效期，不设置是会话级别的, 浏览器关闭，会话结束，数据销毁,可以人为设置cookie的有效期
-
cookie存储容量小，约4kb
// cookie存储数据方式，存储的数据同一个网站可以进行共享，数据量大小是4kb。不同浏览器cookie不能被共享 // cookie必须在服务器环境下使用，不能本地存储和使用 // cookie是会话级别的存储
③cookie的缺点：
-
cookie可能被禁用；
-
cookie与浏览器相关，不能互相访问；
-
cookie可能被用户删除；
-
cookie安全性不够高；
-
cookie存储空间很小(只有4–10KB左右)
④cookie过期时间
// expires可以设置过期时间
// let time = 3 * 60 * 60 * 1000 // 最终毫秒
// let time = 3 * 60 * 60 // 最终秒
// let time = 3 * 60 // 分钟
// 注意点：直接3的话，那么表示的是具体的是什么时间，不知道。所以必须得先获取当前的系统的时间
let d = new Date()
// d.setDate()
// console.log(d.getDate())
// console.log(d.getDay())
// toUTCString()方法转成了标准时区，转成了系统时间
// 注意点1：toUTCString()转换标准时间为系统时间的时候要注意不能跟在时间戳后面
// 注意点2：必须先设置，再进行转换操作
// UTC（Coordinated Universal Time，国际协调时间）
d.setDate(d.getDate()+3)
let t = d.toUTCString()
console.log(t)
document.cookie = `price=2999; expires=${t}`
⑤cookie路径
cookie路径访问限定，外层的不能访问内层的数据
扫一扫
679
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
