Good programmers how to build a web front-end share a single-page Web applications

  Good programmers web front-end share how to build a single-page Web applications , first of all let's look at what is a single-page application ? The so-called single-page application, refers to the variety of functions integrated on a page, or even the entire system is only one page, All business functions that are sub-module, attached to the main interface in a specific way. It is AJAX further sublimation technology, the AJAX played no refresh mechanism to the extreme, it can create a smooth user experience comparable with a desktop program.

 

  In fact, one-page application no stranger to us, a lot of people wrote ExtJS project, which implements a system, it is natural to have a single page, and it was also used jQuery to achieve something similar or other frameworks. With a variety of JS framework, even without the frame, they are able to achieve a single-page application, it's just an idea. Some framework applicable to the development of such a system, if you use them, you can get a lot of convenience.

 

  First, the development framework

 

  ExtJS may be called a first-generation typical application framework of a single page, it encapsulates the various UI components, user mainly uses JavaScript to complete the entire tip portion, even layout. With the increasing functionality, ExtJS volume gradually increases, even for the development of internal systems, sometimes cumbersome, not to mention the development of more than one such system running on the Internet.

 

  jQuery due to the emphasis on DOM operations, its plug-in architecture and relatively loose, so the ratio ExtJS this system is more suitable for single-page system developed in the public network running the entire solution will be relatively lightweight and flexible.

 

  However, due to jQuery mainly for upper operating, it is the lack of organization code constraints. How to control each block of code in the case of rapid expansion cohesion, and generates the appropriate data transfer and sharing between modules, it has become a challenging matter.

 

  To solve the problem code logic to increase the size of single-page application time, there have been many MV * framework, their basic ideas are in the JS layer to create a layered modules and communication mechanisms. Some of MVC , some MVP , some MVVM , and they almost had a variation on these models to adapt to the characteristics of the front-end development.

 

  Such frame includes Backbone , Knockout , the AngularJS , the Avalon like.

 

  Second, component-based

 

  The front end doing layered framework to promote the components of the so-called component-based code in a traditional Web product, referred more UI components, but in fact the component is a broad concept, the traditional Web product UI high proportion of components the reason is lack of its thickness, with the increase of the proportion of the client code, a considerable portion of the front end of the business logic, thereby created a great number of non-interface type components occurs.

 

  One advantage of hierarchical bring is more specific responsibilities of each layer, and thus, covering unit tests can be made thereto, in order to ensure its quality. Traditional UI layer test is the most troublesome problem UI and logical mixed together, such changes tend to remote callback request the DOM , when introduced into a layered, these things can be separately tested, then the test is ensured by the scene the overall process.

 

  Third, the code isolation

 

  Compared with traditional page-based Web site development process to achieve a single-page application, there are some more points of particular concern.

 

  Features a single page from the application point of view, it is more dependent than page-based Web site in JavaScript , and because of a single page, a page of various sub-functions of JavaScript code that gathered in the same scope, so the code isolation, modular becomes Very important.

 

  In a single-page application, the use of page templates is very common. Many built a framework of specific template, and some framework needs to introduce a third party templates. This interface is the template fragments, we can put them into analog JavaScript module, which is another type of assembly.

 

  The same template isolation needs. Not isolated template, it will cause any problems ? Conflicts between template mainly in the id on the property, if a template contains a fixed id , when it is batch rendering time, will result in the same scope have multiple pages the same id of the element, resulting in unpredictable consequences. Therefore, we need to avoid the use of templates in the above mentioned id , if there is to DOM access requirements, should be done by other selectors. If a component of the degree of a one-page application is very high, it is likely there are not elements of the entire application id used.

 

  Fourth, the code is merged with the loading strategy

 

  People for a single page load time tolerance system and Web pages different, if they are willing to wait for a page to load shopping 3 seconds, there might be willing to single-page application is first loaded to wait 5-10 seconds, but after that, use various functions should have relatively smooth, all sub-pages as much as possible to function in 1-2 handover success within seconds, otherwise they will feel that the system is slow.

 

  From these characteristics, we can put more into the public function first loads, to reduce the amount of load each load, there are some sites even put all the interfaces and logic all loaded into the home, every business interface when switched, the data request is generated only, so its response is very fast, such ××× console did.

 

  Usually a single page application, without having to type website like products, in order to prevent obstruction render file loading, the js into html back loaded because its interface is basically dynamically generated.

 

  当切换功能的时候,除了产生数据请求,还需要渲染界面,这个新渲染的界面部件一般是界面模板,它从哪里来呢?来源无非是两种,一种是即时请求,像请求数据那样通过AJAX获取过来,另一种是内置于主界面的某些位置,比如script标签或者不可见的textarea中,后者在切换功能的时候速度有优势,但是加重了主页面的负担。

 

  在传统的页面型网站中,页面之间是互相隔离的,因此,如果在页面间存在可复用的代码,一般是提取成单独的文件,并且可能会需要按照每个页面的需求去进行合并。

 

  单页应用中,如果总的代码量不大,可以整体打包一次在首页载入,如果大到一定规模,再作运行时加载,加载的粒度可以搞得比较大,不同的块之间没有重复部分。

 

  五、路由与状态的管理

 

  我们最开始看到的几个在线应用,有的是对路由作了管理的,有的没有。

 

  管理路由的目的是什么呢?是为了能减少用户的导航成本。比如说我们有一个功能,经历过多次导航菜单的点击,才呈现出来。

 

  如果用户想要把这个功能地址分享给别人,他怎么才能做到呢?

 

  传统的页面型产品是不存在这个问题的,因为它就是以页面为单位的,也有的时候,服务端路由处理了这一切。

 

  但是在单页应用中,这成为了问题,因为我们只有一个页面,界面上的各种功能区块是动态生成的。所以我们要通过对路由的管理,来实现这样的功能。

 

  具体的做法就是把产品功能划分为若干状态,每个状态映射到相应的路由,然后通过pushState这样的机制,动态解析路由,使之与功能界面匹配。

 

  有了路由之后,我们的单页面产品就可以前进后退,就像是在不同页面之间一样。

 

  其实在Web产品之外,早就有了管理路由的技术方案,AdobeFlex中,就会把比如TabNavigator,甚至下拉框的选中状态对应到url上,因为它也是单“页面”的产品模式,需要面对同样的问题。

 

  当产品状态复杂到一定程度的时候,路由又变得很难应用了,因为状态的管理极其麻烦,比如开始的时候我们演示的c9.io在线IDE,它就没法把状态对应到url上。

 

  六、缓存与本地存储

 

  在单页应用的运作机制中,缓存是一个很重要的环节。

 

  由于这类系统的前端部分几乎全是静态文件,所以它能够有机会利用浏览器的缓存机制,而比如动态加载的界面模板,也完全可以做一些自定义的缓存机制,在非首次的请求中直接取缓存的版本,以加快加载速度。

 

  甚至,也出现了一些方案,在动态加载JavaScript代码的同时,把它们也缓存起来。比如AddyOsmani的这个basket.js,就利用了HTML5localStorage作了jscss文件的缓存。

 

  在单页产品中,业务代码也常常会需要跟本地存储打交道,存储一些临时数据,可以使用localStorage或者localStorageDB来简化自己的业务代码。

 

  七、服务端通信

 

  传统的Web产品通常使用JSONP或者AJAX这样的方式与服务端通信,但在单页Web应用中,有很大一部分采用WebSocket这样的实时通讯方式。

 

  WebSocket与传统基于HTTP的通信机制相比,有很大的优势。它可以让服务端很便利地使用反向推送,前端只响应确实产生业务数据的事件,减少一遍又一遍无意义的AJAX轮询。

 

  由于WebSocket只在比较先进的浏览器上被支持,有一些库提供了在不同浏览器中的兼容方案,比如socket.io,它在不支持WebSocket的浏览器上会降级成使用AJAXJSONP等方式,对业务代码完全透明、兼容。

 

  八、内存管理

 

  传统的Web页面一般是不需要考虑内存的管理的,因为用户的停留时间相对少,即使出现内存泄漏,可能很快就被刷新页面之类的操作冲掉了,但单页应用是不同的,它的用户很可能会把它开一整天,因此,我们需要对其中的DOM操作、网络连接等部分格外小心。

 

  九、样式的规划

 

  在单页应用中,因为页面的集成度高,所有页面聚集到同一作用域,样式的规划也变得重要了。

 

  样式规划主要是几个方面:

 

  1、基准样式的分离

 

  这里面主要包括浏览器样式的重设、全局字体的设置、布局的基本约定和响应式支持。

 

  2、组件样式的划分

 

  这里面是两个层面的规划,首先是各种界面组件及其子元素的样式,其次是一些修饰样式。组件样式应当尽量减少互相依赖,各组件的样式允许冗余。

 

  3、堆叠次序的管理

 

  传统Web页面的特点是元素多,但是层次少,单页应用会有些不同。

 

  在单页应用中,需要提前为各种UI组件规划堆叠次序,也就是z-index,比如说,我们可能会有各种弹出对话框,浮动层,它们可能组合成各种堆叠状态。新的对话框的z-index需要比旧的高,才能确保盖在它上面。诸如此类,都需要我们对这些可能的遮盖作规划,那么,怎样去规划呢?

 

  了解通信知识的人,应当会知道,不同的频率段被划分给不同的通信方式使用,在一些国家,领空的使用也是有划分的,我们也可以用同样的方式来预先分段,不同类型的组件的z-index落到各自的区间,以避免它们的冲突。

 

  十、单页应用的产品形态

 

  我们在开始的时候提到,存在着很多新型Web产品,使用单页应用的方式构建,但实际上,这类产品不仅仅存在于Web上。点开Chrome商店,我们会发现很多离线应用,这些产品都可以算是单页应用的体现。

 

  除了各种浏览器插件,借助node-webkit这样的外壳平台,我们可以使用Web技术来构建本地应用,产品的主要部分仍然是我们熟悉的单页应用。

 

  单页应用的流行程度正在逐渐增加,大家如果关注了一些初创型互联网企业,会发现其中很大一部分的产品模式是单页化的。这种模式能带给用户流畅的体验,在开发阶段,对JavaScript技能水平要求较高。

 

  单页应用开发过程中,前后端是天然分离的,双方以API为分界。前端作为服务的消费者,后端作为服务的提供者。

 

  在此模式下,前端将会推动后端的服务化。当后端不再承担模板渲染、输出页面这样工作的情况下,它可以更专注于所提供的API的实现,而在这样的情况下,Web前端与各种移动终端的地位对等,也逐渐使得后端API不必再为每个端作差异化设计了。

 

  十一、部署模式的改变

 

  在现在这个时代,我们已经可以看到一种产品的出现了,那就是“无后端”的Web应用。这是一种什么东西呢?基于这种理念,你的产品很可能只需要自己编写静态Web页面,在某种BaaS(BackendasaService)云平台上定制服务端API和云存储,集成这个平台提供的SDK,通过AJAX等方式与之打交道,实现注册认证、社交、消息推送、实时通信、云存储等功能。

 

  我们观察一下这种模式,会发现前后端的部署已经完全分离了,前端代码完全静态化,这意味着可以把它们放置到CDN上,访问将大大地加速,而服务端托管在BaaS云上,开发者也不必去关注一些部署方面的繁琐细节。

 

  假设你是一名创业者,正在做的是一种实时协同的单页产品,可以在云平台上,快速定制后端服务,把绝大部分宝贵的时间花在开发产品本身上。

 

  十二、单页应用的缺陷

 

  单页应用最根本的缺陷就是不利于SEO,因为界面的绝大部分都是动态生成的,所以搜索引擎很不容易索引它。

 

  十三、产品单页化带来的挑战

 

  一个产品想要单页化,首先是它必须适合单页的形态。其次,在这个过程中,对开发模式会产生一些变更,对开发技能也会有一些要求。

 

  开发者的JavaScript技能必须过关,同时需要对组件化、设计模式有所认识,他所面对的不再是一个简单的页面,而是一个运行在浏览器环境中的桌面软件。


Guess you like

Origin blog.51cto.com/14249543/2407477