命名规范

页面（Page）

参考：ionic命令行Generate体验总结

开发规范

1. 通过命令行创建初始化页面

   ## 通常使用命令创建新的页面初始文件（Page）
   ionic g page <PageName>
   

2. 页面只写布局与用户操作，所有数据相关的通知Toast、数据处理相关的Modal，都统一在Provider中实现

命名规范

根据ionic generte命令，页面的命名方式为：

• 目录名称 /app/pages/my-about/
• 文件名称 my-about.html
• scss样式 .my-about
• class名称 MyAboutPage

Ionic 2 uses kebob-casing for file names (my-about.html) and css classes (.my-about), and uses PascalCasing for JavaScript classes in ES6/TypeScript (MyAboutPage). Using this convention, developers can pick up any Ionic 2 project and quickly become productive, similar to Rails.

创建时不需要输入Page，在ES6文件中，class名会自动补全Page后缀，以便在大型项目中识别该控件为页面（Page）类型。

命名示例（以生成时用的PascalCasing为例）：

• 标签页 Tabs/TabsPms/TabsShop/TabsShop
• 用户相关 User/UserInfo/UserRelation/UserConf
• 项目相关 Pms/PmsProject/PmsStage/PmsTask
• 商城相关 Shop/ShopItem/ShopCate/ShopOrder

组件使用规范

数据处理时的页面导航？

数据处理时，应统一采用事件触发机制调控页面导航

情景一：应用使用中用户token口令失效，从app.js中触发调用Events事件user:logout，页面push至登录页。

数据处理应统一使用Promise，增强应用异步特性

全局事件

用户类事件

• user:login
• user:logout
• user:signup

通知类事件

优点： - 减少冗余Toast、Modal控件代码 - 便于统一管理各页面的消息通知（统一存储、统一记录）

疑问： - 较多得引用同一个Event，是否会调用冲突，是否异步执行？ - Event的性能开支，是否抵得上减少的冗余代码？

所有通知需要通过事件进行触发，如无特殊情况，不建议在Page中自己写Toast控件！

let eventData = {
  status: "通知的状态",
  type: "通知的方式",
  message: "通知内容"
}
this.events.publish('user:notify', eventData);