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/ 编译后的前端资源

如何开发？

1. npm install
2. 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(未授权)。此外,响应体中应该有错误具体情况的 说明。如果你想做得更好,错误消息中甚至应该包含文档的链接。注意,如果用户请求 的是一个列表,但没有东西返回,这不是错误:返回空列表是恰当的响应。