购物车构建与组件样式设计全解析
1. 购物车应用的可扩展性考量
在构建购物车应用时，若要实现应用的可扩展性，有两个方面值得改进。
首先是事件处理传递问题。在小型示例中，将事件处理程序传递给子组件并监听子组件返回数据的方式或许可行。但在实际应用里，这种工作流程的追踪会变得极为困难。因为子组件可能嵌套很深，即便中间组件不需要该事件属性，也得进行传递。为解决此问题，可采用不同方法：当子组件需要将数据（属性）回传给父组件时，可将动作分发到一个通用函数，该函数能修改父组件上层的顶级数据，再将数据向下传递。调用父组件的 Meteor 方法就类似这种操作，响应式容器会再次传递属性。不过，还有更优方案。这种子组件向父组件传递数据的需求催生了 Flux 架构，也影响了其他类似方法的发展。其中，Redux 因其简单性，迅速成为最受欢迎的方案之一。
其次是保存用户操作状态。目前虽能获取前一个状态、新状态、下一个属性和当前属性，但组件状态是内部的，属性从父组件传递给子组件，无法回溯查看用户的所有操作。此时，Redux 或类似库就能发挥作用，借助 Redux 可管理应用所需持久化的所有状态。
有人可能会想，借助 Meteor 在客户端拥有数据库，能否将所有应用状态保存其中并按需查询呢？可以创建本地集合存储所需内容，或使用全局会话变量管理状态，但这会导致管理本地集合被覆盖的困难，且全局变量并非存储应用状态的最佳方式。
2. 服务器端的基本验证
在服务器端，可使用特定包进行类型检查：
import { check } from 'meteor/check';
