关于Web App

咋们现今说的web app，现阶段亦可简要定义为OPOA，或者再详细一点是经由 路由（hash）驱动的OPOA，单页应用。开发这种类型的应用，需要关注的几个点，大致可以归结为以下几个方面。

1. hash驱动： 现在主流的方案都是 hashchange + history[pushState] 来做。每一个 #hash的变更对应一个 单页应用 “子App”的加载和启动。好的和强大的router机制就显得尤为重要。将hash的匹配转化为对应的js可执行方法，主流的web app 的框架基本都是此做法，通过hash匹配对应的function，此为“驱动”。
2. 子路由和hash持久化：当然单页应用复杂起来，除了会衍生出很多“子app”，可能在每个“子app”里面也需要更为细分的“路由驱动和持久”。比如一个“子app”里面有翻页，或者富交互的弹层等... 所谓持久化，即为每一个“有意义”的url都能使页面还原为预期的样子，比如子路由里面带页码，带tabid，带弹层显示与否的flag。一旦有这种在交互设计中有意义的参数，实现上都应该记入持久化考虑的范畴（除非这个产品交互本身就不要求）。页面完全按照url的要求而表现。
   当然也可以用url之外的东西来完成持久化的功能，比如记入cookie或者localstorage来做。但既然你已经有了一套完善的router机制，为什么不用呢？
3. 数据异步化：web app和web page还有个较大的不同点在于 web page是server端直接吐页面，异步数据可能也是页面中局部的模块在用。但是web app是整站，整个app都是异步数据接口在做。server端只负责从数据库中挖数据做拼装。数据parse，数据填模版都是前端的工作。大量的异步接口和数据必然导致异步编程体验。改善异步编程体验，这是一份重要的工作。这就需要你有一套好的Model机制。Backbone很多人喜欢用，除了它有我上面说的较为的完善router机制外，还在于它也把异步的数据请求体验通过 message 改善了不少。
   fetch或者Model.set的时候自动会触发 ‘model.change’事件。其实对于消息订阅机制稍微熟悉一点的高级开发者，这种消息机制完全可以自己实现，并且代码量极少。关键在于你的思路有木有跟上。

<script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>