前端单页 Web 应用的数据管理

单页 Web 应用相较于传统的 Web 页面通常都具有较长的生命周期，页面（前端路由实现的"虚拟页面"）切换时的数据如何有效的保存或销毁，应用会不会内存泄漏亦或是内存会不会被无限制的使用而导致系统资源耗尽。基于这样的应用场景，数据的通信和传输、管理和存储对于前端单页 Web 应用来说越来越重要。而如何基于单页 Web 应用的 UI 渲染模式设计出与之契合的数据管理的架构模式，这是我一直在尝试和探索的方向。

基于 React 的单页 Web 应用，Flux 在目前仍然是较好的架构模式，但 Flux 更多的是侧重于数据的通信和传输，在这方面，我在之前的 Ballade: 重新诠释 Flux 架构 中有详细的介绍。

而本文主要介绍的是数据的管理和存储，并且在这方面是可以脱离于 Flux 的架构模式去独立探索和发展的。

为什么会有 Schema ？

如果把 Flux 架构中的 Store 看作是一个简单的数据库的话，那么从数据库中读取出来的数据的可靠性就直接影响到 UI 界面是否能正常渲染。

Schema 的概念源于数据库中的数据存储，为了确保数据在存储到数据库中的时候数据是「可控」的，可以在存储数据时对数据结构、数据类型进行预定义，只有符合定义好的条件时才会存入。

在 Ballade 应用于前端开发中的时候，我们可以把 Store 当作一个简单的前端数据库，界面中所有的数据都是来源于 Store，Schema 确保了数据库的「写入」是可控的，那么从其中「读取」的数据也会是可控的。如果前端的数据都是可控的话，那么可以确保前端的界面不会因为数据的错误、异常而出现问题。这样一来，数据可控也就意味着界面可控。

Ballade 的 Schema 的设计思想就来源于 Mongoose Schema。

Schema 在 Ballade 中的应用

假如定义了下面这样一组 Schema.

var photoItemSchema = new Schema({
        category: String,
        title: {
            $type: String,
            $trim: true
        },
        tags: [String],
        width: {
            $type: Number,
            $min: 100,
            $mx: 1000
        }
    });

即将存储到 Store 中的实际数据可能是这样的。

{
        category: '风光',
        error: {
            code: 400
        },
        title: ' 美景 ',
        tags: ['风光', '旅行', 3],
        width: 200
    }

Schema 会对即将存储的数据进行校验，最终存储到 Store 中的数据结果可能是这样的。

{
        category: '风光',
        title: '美景',
        tags: ['风光', '旅行', '3'],
        width: 200  
    }

• 由于 error 字段并未在 Schema 中定义，所以它在存储的时候会被直接忽略。
• title 中的首尾空格会自动进行 trim 的处理。
• tags 中的数值 3 会自动转换成字符串的 '3'，因为在 Schema 中已经定义了该数组的数组项必须为字符串，所以它会根据定义的类型尝试自动转换。
• 如果 width 的实际值为 90 会怎么处理呢，因为 width 的定义了 $min 最小值和 $max 最大值，不在规定的范围内的值，就会直接抛出错误。

能转换的都会给出 warning 信息，转换失败或本身就不符合规则的值就直接抛出 error 的信息，UI 界面再依据相应的信息去做对应的渲染处理。

关于 Schema 的详细说明，可以看官方的 Schema 文档。

Store 中的缓存设计

对于请求频次高的数据存储场景来说，前端适当的缓存数据，可以有效的降低对服务端的请求压力。比如在单页应用中对某个大列表进行分页加载时，大部分时候已加载过的数据不应该再发起第二次请求，这是前端缓存的便利性。

但是单页应用中如果对数据进行无限制的缓存，会导致浏览器的内存暴涨，最终耗光系统的资源。此时有限制性的缓存很有必要。通过使用 Ballade 提供的缓存模块，可以确保缓存到 store 中的数据不会无限的增长。

先定义 Schema。

var schema1 = new Schema({
        photo: {
            id: String,
            title: String,
            width: Number,
            height: Number
        }
    });

    var schema2 = new Schema({
        avatar: String,
        photos: {
            key: String,
            list: [schema1],
            total: Number
        }
    });

对 photos 的数据进行限制长度的缓存，需要在创建 Store 时设置 cache 的配置。

var options = {
        cache: {
            photos: {
                id: 'key',  // 设置 key 作为缓存的唯一 id
                maxLength: 10 // 设置缓存数据的最大长度
            }
        }
    };

在限制长度的缓存中，需要指定一个 id 字段，该字段的值必须确保是唯一的，如上面 photos 的数据就使用 key 这个字段来作为缓存的唯一 id 字段名。

创建 Store 时传上该配置即可。

var store = dispatcher.createImmutableStore(schema2, options, {
        'fetch-photos': (store, action) => {
            const photos = action.response.data;
            photos.key = action.key;
            // 存入 Store，并且具备缓存数据的能力
            store.set('photos', photos);
        }
    });

在 UI View 中获取 Store 中的数据还需带上对应的数据 id。

var id = '001';
    store.get('photos', id); => 直接输出 001 对应的数据

其中 maxLength 可以限定缓存数据的最大长度，如果超出最大长度，则会采用先进先出的策略，先清除最先缓存的数据，然后才缓存新的数据。

持久化的 Store

很多时候，单页应用期望能将一些数据持久化到本地，通过集成 localStorage 和 sessionStorage 就可以进行持久化的缓存。

Ballade 的缓存模块可以将数据持久化到本地，无需直接操作 localStorage 和 sessionStorage，只要在数据存储时指定 persistence 选项即可。

对于上面的例子来说，想对 avatar 的数据做本地缓存，那么缓存配置应该是这样的：

const options = {
        cache: {
            avatar: {
                persistence: {
                    type: 'localStorage',
                    prefix: 'user'
                }
            }
        }
    };

其中 persistence.type 指定的持久化的类型，persistence.prefix 指定的持久化缓存的前缀，避免数据存储时的存储 key 的冲突。

访问缓存的数据与之前获取 Store 中的用法没有差别，应用在启动的时候会自动从本地缓存中获取持久化的数据。

store.get('avatar'); => 输出 avatar 的持久化缓存数据

需要注意的是使用 Ballade 向 localStorage 存储数据时非常便捷，但也需要考虑应该什么时候清除该数据，以避免持久化缓存的空间无限膨胀。

当然，持久化的缓存可以和普通的缓存结合使用。

结语

前端单页应用的数据层除了数据校验、缓存的尝试，还可以更多的去考虑怎么和 UI 绑定以降低数据和 UI 的逻辑，思想上也可以多去思考服务端有哪些经验是值得借鉴的。

Ballade 的文档：https://github.com/chenmnkken/ballade/blob/master/README_CN.md