我还在携程的做业务的时候，每个看似简单的移动页面背后往往会隐藏5个以上的数据请求，其中最过复杂的当属机票与酒店的订单填写业务代码

这里先看看比较“简单”的机票代码：

然后看看稍微复杂的酒店业务逻辑：

机票一个页面的代码量达到了5000行代码，而酒店的代码竟然超过了8000行，这里还不包括模板（html）文件！！！

然后初略看了机票的代码，就该页面可能发生的接口请求有19个之多！！！而酒店的的交互DOM事件基本多到了令人发指的地步：

当然，机票团队的交互DOM事件已经多到了我笔记本不能截图了：

1 events: { 'click .flight-hxtipshd': 'huiXuanDesc', 'click .js_ListReload': 'hideNetError', 'click div[data-rbtType]': 'showRebate', 'click #paybtn .j_btn': 'beforePayAction', 'click .flight-loginbtn2': 'bookLogin', 'input #linkTel': 'setContact', 'click #addPassenger .flight-labq': 'readmeAction','click .jsDelivery': 'selDelivery', 'click #jsViewCoupons': 'viewCoupons', 'click .js_del_tab': 'showDelListUI', 'click #js_addrList': 'AddrListAction', 'click #date-picker': 'calendarAction', 'click #done-address': 'zqinairselect', 'click #selectCity': 'selectCityAction', 'click #date-zqtime': 'showZqTimeUI', 'click #jsinsure': 'viewInsure', 'click #js_invoice_title': 'inTitleChangeWrp', 'click #js_invoice_title_div': 'inTitleChangeWrp', 'focusin #linkTel': 'telInput', 27 'focusout #linkTel': 'telInputFinish', 'click #package .flight-arrrht': 'packageSelect', 30 'focusin input': 'hideErrorTips', 31 'click #dist_text_div': 'hideErrorTips', 32 'click .j_PackageNotice': 'toggletips', 33 'click .j_AnnouncementNotice': 'toggleNotice', 'click #airInsureDesc': 'showAirInsureDesc', 'click .J_retriveVerifyCodeBtn': 'getVerifyCode', 38 'click .J_toPay': 'toPayAction', 39 'click .J_closeVerifyCode': 'closeVerifyCodePopup', 40 'keyup .J_verifyCodePopup input': 'setToPayBtnStatus', 'click .j_changeFlight': 'changeFlightAction', 'focusin input:not([type=tel])': 'adjustInputPosition', 'click .js_addr,#js_addr_div': 'editDeliverAddress','click .js_showUserInfo': 'showUserInfo', 'click #logout': 'logout', 'click #gotoMyOrder': 'gotoMyOrder', 'touchstart #logout': function (e) { $(e.currentTarget).addClass('current'); }, 49 'touchstart #gotoMyOrder': function (e) { $(e.currentTarget).addClass('current'); }, 50 'click .js_buddypayConfirm': 'buddypayConfirmed', 'click .flt-bking-logintips': 'closelogintips'},

就这种体量的页面，如果需要迭代需求、打BUG补丁的话，我敢肯定的说，一个BUG的修复很容易引起其它BUG，而上面还仅仅是其中一个业务页面，后面还有强大而复杂的前端框架呢！如此复杂的前端代码维护工作可不是开玩笑的！

PS：说道此处，不得不为携程的前端水平点个赞，业内少有的单页应用，一套代码H5&Hybrid同时运行不说，还解决了SEO问题，嗯，很赞。

如何维护这种页面，如何设计这种页面是我们今天讨论的重点，而上述是携程合并后的代码，他们两个团队的设计思路不便在此处展开。

今天，我这里提供一个思路，认真阅读此文可能在以下方面对你有所帮助：

1 ① 如何将一个复杂的页面拆分为一个个独立的页面组件模块 2 ② 如何将分拆后的业务组件模块重新合为一个完整的页面 ④ 从前端优化的角度看待组件化开发

文中是我个人的一些框架&业务开发经验，希望对各位有用，也希望各位多多支持讨论，指出文中不足以及提出您的一些建议。

由于该项目涉及到了项目拆分与合并，基本属于一个完整的前端工程化案例了，所以将之放到了github上：https://github.com/yexiaochai/mvc

其中工程化一块的代码，后续会由另一位小伙伴持续更新，如果该文对各位有所帮助的话请各位给项目点个赞、加颗星：）

我相信如果是中级水平的前端，认真阅读此文一定会对你有一点帮助滴。

代码仓促，可能会有BUG哦：）

代码地址：https://github.com/yexiaochai/mvc/

因为订单填写页一般有密度，我这里挑选相对复杂而又没有密度的产品列表页来做说明，其中框架以及业务代码已经做过抽离，不会包含敏感信息，一些优化后续会同步到开源blade框架中去。

我们这里列表页的首屏页面如下：

简单来说组成如下：

① 框架级别UI组件UIHeader，头部组件

② 点击日期会出框架级别UI，日历组件UICalendar

③ 点击出发时段、出发汽车站、到达汽车站，皆会出框架级别UI

④ header下面的日期工具栏需要作为独立的业务模块

⑤ 列表区域可以作为独立的业务模块，但是与主业务靠太近，不太适合

⑥ 出发时段、出发汽车站、到达汽车站皆是独立的业务模块

一个页面被我们拆分成了若干个小模块，我们只需要关注模块内部的交互实现，而包括业务模块的通信，业务模块的样式，业务模块的重用，暂时有以下约定：