12 本地存储

1. window.sessionStorage
2. window.localStorage

1 本地存储

随着互联网的快速发展，基于网页的应用越来越普遍，同时也变的越来越复杂，为了满足各种各样的需求，会经常性在本地存储大量的数据，HTML5规范提出了相关解决方案。

本地存储特性

1、数据存储在用户浏览器中

2、设置、读取方便、甚至页面刷新不丢失数据

3、容量较大，sessionStorage约5M、localStorage约20M

4、只能存储字符串，可以将对象JSON.stringify() 编码后存储

2window.sessionStorage

1、生命周期为关闭浏览器窗口

2、在同一个窗口(页面)下数据可以共享

3、以键值对的形式存储使用

存储数据：sessionStorage.setItem(key, value)

获取数据：sessionStorage.getItem(key)

删除数据：sessionStorage.removeItem(key)

删除所有数据：sessionStorage.clear()

==01-sessionStorage案例代码==

3 window.localStorage

1、声明周期永久生效，除非手动删除 否则关闭页面也会存在

2、可以多窗口（页面）共享（同一浏览器可以共享）

3、以键值对的形式存储使用

存储数据：localStorage.setItem(key, value)

获取数据：localStorage.getItem(key)

删除数据：localStorage.removeItem(key)

删除所有数据：localStorage.clear()
==02-本地存储之localStorage==

案例：记住用户名

如果勾选记住用户名， 下次用户打开浏览器，就在文本框里面自动显示上次登录的用户名

案例分析

① 把数据存起来，用到本地存储

② 关闭页面，也可以显示用户名，所以用到localStorage

③ 打开页面，先判断是否有这个用户名，如果有，就在表单里面显示用户名，并且勾选复选框
④ 当复选框发生改变的时候 change事件

⑤ 如果勾选，就存储，否则就移除

==03-案例之网站保存密码功能==

4 对象数据的编码与解析

4.1 JSON.stringify(obj)

如果直接将对象数据存到本地，格式会变成字符串的：[object Object] 不是我们需要需要的数据格式。

需要将对象编码后存储： JSON.stringify(obj)—>返回一个字符串

会编码成对象格式的字符串。我们称之为JSON字符串或者JSON对象

4.2 JSON.parse(str)

如果从本地存储获取的是字符串类型对象格式数据。需要解析为对象类型才是我们需要的

解析：JSON.parse(str)—>返回一个对象

==04-本地存储之存储对象==

5 本地存储项目之马哥记事本

业务分析：

1. 页面加载完成需要执行：

   • 从本地存储获取todoList转成数组对象todoList。JOSN.prase()
   • 判断是否获取到数组。如果获取不到。
     • 待办事项模块的数据统计：0
   • 如果获取到数据了
     • 遍历数组创建页面元素。同时将每一个数组元素添加到对应位置。
     • 待办事项模块的数据统计：todoList数组的长度。

2. 添加功能：setItem(todoList , 新数组对象编码后的字符串)

   • 输入框onkeyup事件。判断是否enter键。
     • 将当前的输入框内容：todoList.push(当前输入的文本内容)；记得更新本地存储中的todoList
     • 刷新当前页面：location.reload();

3. 单个删除：不是用的本地存储的removeItem(key)

   • 点击每一条记录的后面的X号。移除本地存储的该条记录。
     • 先获取本地存储的数组对象。删除指定索引或者文本的那一条记录。此时的数组是更新后的数组。
     • 将删除过数据的数组，重新存进去。
     • 刷新当前页面：location.reload();

4. clear模块：

   • 移除本地数据：localStorage.removeItem(todoList)
   • 移除之后记得刷新当前页面：location.reload();

6 本地存储项目之情话站

已上线，可测试和借鉴

表设计

用户表：userArr

因为此时用的是本地存储功能。存多个用户对象到数组中。所以设计键名为userArr.后期升级为数据库的时候，表明可以按照数据库的格式来取，比如user或者user_tab

本地存储的数据结构如下

  let userArr = [
        {
            id: +new Date(),
            username: '张三',
            password: '3333',
            picture: 'images/defaultAvatar.jpg',
            createTime: '当时注册的时候的格式化时间，其实和ID的时间戳时相同的，只不过ID是一长串数字，现在我格式化了',
            updateTime: '修改用户时的时间戳格式成的字符串 默认给空',
            enabled:true
        }, {
            id: +new Date(),
            username: '李四',
            password: '4444',
            picture: 'images/defaultAvatar.jpg',
            createTime: '当时注册的时候的格式化时间，其实和ID的时间戳时相同的，只不过ID是一长串数字，现在我格式化了',
            updateTime: '修改用户时的时间戳格式成的字符串  默认给空',
            enabled:true
        },
        ......
    ]

留言表：messageArr

enable字段 遍历数据到页面的时候，不应该是所有数据，而前提是enabled=true的时候。获取数据的时候，应该由后端查询数据库给我们。他们会通过sql语句。select from message_tab where enabled = true。获取的已经是所有公开数据。 而此时我们遍历数据到页面，获取数据是咱们自己js代码从本地存储获取的。不像后端操作数据库那样在获取的时候就可以设置某些筛选条件。我们此时只能localStorage.getItem(‘messageArr’) 得到的是所有数据。需要进一步清洗数据得到enabled=true的数据。 public字段： 因为这个字段的存在。所以数据遍历到页面的时候，依旧需要进行数据清洗。在哪中数据中进行清洗，在上一步所有启用的数据中进行清洗。前提是数据没被删除过。是启用状态 用户登陆：哪种是自己看不到？其他用户的隐私数据我就不该看到。换言之：自己能看到的数据是哪些： 在所有启用的数据中： 自己所有的数据+所有公开的数据？这里是有逻辑bug的。会有冗余数据，也叫脏数据。所有公开的数据和自己所有的数据是有一个交集的。这种逻辑是会有重复数据的。那么在页面上就会重复显示相同的数据。 所有公开的数据+自己隐私的数据：这种才是应该显示给登陆用户看的数据 别人公开的+自己所有的：这种也可以。 *游客状态： 所有公开的数据：直接查所有公开数据就是游客应该看到的

功能分析：

1：用户注册模块

• 用户名验证

  • 用户名长度是否合法
  • 是否占用

    验证逻辑： 用户名和密码都是动态验证。输入完光标离开就验证，不满足就给提示信息。 用户名需要查DB 中（状态为可用的数据）是否存在。如果不存在，需要验证长度是否合法。

• 注册功能

  • 先判定能够注册

    验证都合法的情况。才给注册按钮绑定事件去完成注册功能。

  • 提交注册

    DB字段需要思考。目前注册页面提示出来的信息，只有用户名和密码。 实际想要看到的用户信息还要包含： 用户头像：方便在展示留言的时候显示该用户的图片。 不能使用用户名区别不同的用户。因为后期个人中心模块要修改用户的信息包含用户名，密码，头像等字段。如果使用用户名作为唯一标识。如果把该用户名也修改了。留言表中的留言者在用户表中就找不到了。 经过上面的分析：用户表中还需要一个字段 用户唯一标识ID：点击注册的时候会有一个唯一的时间戳。可以用来作为ID。 当然了，如果用户量特别多，在某个时间戳节点有多人注册，那就不唯一了。但是我们现在的小破网站，而且只有前端完成，可以暂时使用。后端会有UUID来替换时间戳。 用户是否启用：意思就是是否是注销状态。 如果是注销状态。登陆的时候。应该不能成功。如果他之前操作注销账号的时候，不要直接把他这一条数据从DB给删除。方便后期再次回来的时候，我们欢迎回来。我们怎么知道，他是之前的那个人呢？可是重新注册的时候，是不是还要去数据库查询。如果你现在注册的用户名已经存在了。你就没办法注册了。所以，我想这样，如果某天他重新注册的时候，用户名和之前的用户名还相同。还能注册。说明注册的验证是否存在用户这个逻辑，要从所有正常的用户里面查找，不包含已经注销的用户。此时可以注册了。注册成功的时候，不关心他的密码是否是上次的密码，在注册成功后去已经注销过的用户里匹配一下。 匹配上行了：欢迎重新回来。此时记得修改原DB中的注销的该用户的信息：启用，密码，注册时间保持不变。

    匹配不上：注册成功是新用户。默认启用状态时true

    也可以不通过上面的逻辑来识别是否为曾经注销过的用户：主要思路就是在用户里找一个唯一 的，不重复的字段，而ID因为是时间戳，已经过去了，后来重新回来注册的时候，匹配不上了。不能用了。那就需要再找一个不重复的字段，只剩下用户名了。如果能再有一个唯一的字段比如手机号。那就可以通过手机号来判断了。这也是正常的做法。我们此时不根据手机号来判定原因是没有学手机短信验证功能。此时小破站没有必要。 注册时间：第一次注册成功的格式化时间。 修改时间：只记录最后一次修改时间。也就是，如果没有修改过。值为空。如果修改过，保存修改时的格式化时间。如果后面再次修改，值被覆盖为再次修改的实格式化时间。