Structure
potato/
├── articles/
├── server/ 服务端代码
│ ├── controller/
│ ├── model/
│ ├── data/
│ ├── db/
│ └── index.js
├── client/ 客户端代码
│ ├── pages // 页面
│ │ ├── page1
│ │ │ ├── index.js
│ │ │ ├── index.css
│ │ │ └── index.jade
│ │ └── page2
│ ├── assets // 静态资源
│ │ ├── vendors // 第三方库
│ │ ├── kits // 小组件
│ │ ├── img
│ │ ├── less
│ │ └── js
│ │ ├── controller 协调model和views
│ │ └── model
│ ├── index.js 页面首页(对应views/index.jade)，SPA应用只需这一个
│ ├── home.js client目录下的js文件为entry,且必须要有viwes下对应的同名模版文件
│ └── index.less
│
├── views/ HTML模版
│ ├── common/
│ ├── index.jade
│ ├── home.jade
│ ├──
│ └──
└── dist/ 编译后的前端资源
如何开发？
- npm install
- npm run dev
依赖
- jquery
- underscore
- backbone
eslint
设置全局变量：$,_,B
webpack
设置全局变量(通过webpack.ProvidePlugin): $,_,B
gulp
gulp.md
webpack
webpack.md
mongodb
jade
koa
tape
underscore
backbone
jQuery
单页应用可以做到一举两得，桌面应用的及时性，网站的可移植性和可访问性。
Shell (master controller)
Shell负责:
- 渲染和管理功能容器
- 管理应用状态
- 协调功能模块
使用URI来驱动页面状态的解决方案，我们叫做锚接口模式(anchor interface pattern)
为了确定事件引起的变化是否值得支持历史功能，我们要问自己以下三个问题：
- 用户想把发生的变化添加为书签的愿望有多强烈？
- 用户想恢复到变化发生之前的页面的状态的愿望有多强烈？
- 支持这一功能又多昂贵？
我们希望始终让锚组件来驱动可书签化的应用状态。这能确保历史功能一直按预期工作。
我们设计的和应用交互的功能模块，和第三方模块的做法很像：
- 精心定义的API
- 强隔离性 这可以更快的发布，质量也更高，因为我们可以关注创建能增值的核心模块，次要的模块可以交给第三方。 这种策略也提供了一种清晰的优化方案，因为只要时间和资源允许，我们就可以有选择地用更好的模块来替换第三方模块。 我们也可以在多个项目之间很容易地重用模块，这是一个额外的好处。
精心编写的第三方模块具有以下共同特性：
- 它们在自己的容器内渲染，容器要么由别人提供，要么由它们自己添加到文档上。
- 它们提供了精心定义的API，以便控制它们的行为。
- 它们通过将自己的JS、数据和css精心的隔离，避免污染主页面。
Model不做什么
- Model不需要浏览器。这意味着Model不可以假定存在document对象，或者存在像document.location这种浏览器特有的方法。
- Model不提供通用的工具方法。
- Model不直接和服务器通信。这有一个单独的模块，叫做Data。
我们对事件处理程序的命名规范是：on[]
单页服务器更精简更专注，比如持久化数据存储、数据验证、用户认证和数据同步。
单页应用Web服务器最常见的职责是认证与授权、数据验证和 数据的存储与同步。
一般来说,错误可以分为以下几类。
- 灾难性错误 导致服务器的状态不稳定或不可知的错误。这种错误一般是未处理异常导致的。从灾难 性错误中恢复的唯一办法是重启服务器。理想情况下,所有挂起的请求都会收到响应码 500,但如果故障很严重,服务器可能根本无法响应,请求会超时。
- 可恢复的服务器错误 可恢复错误不需要服务器重启,或其他任何壮烈的动作。这种错误一般是服务器上未预 料到的错误条件导致的(比如不可用的数据库连接)。问题可能是暂时的或永久的。这 种情况下应该返回响应码 500。
- 客户端错误 客户端错误是客户端犯了错误,一般是参数漏掉了或参数无效。这时不应该用响应码 500,毕竟服务器没有故障。一切都正常,只是客户端没有正确使用 API。此时你有两 个选择:可以用状态码 200,并在响应体中描述错误,或者你可以尝试额外用恰当的 HTTP 状态码描述错误。我建议用后一种方式。这种情况下最合适的响应码是 404(未找到)、400(错误的请求)和 401(未授权)。此外,响应体中应该有错误具体情况的 说明。如果你想做得更好,错误消息中甚至应该包含文档的链接。注意,如果用户请求 的是一个列表,但没有东西返回,这不是错误:返回空列表是恰当的响应。