How to quickly develop spa applications

Objective

The web has entered the 2.0 era, today's Web page to the system application level of the trend of development, is not the previous simple display of information interface. Now many WebApp have done the native application function, and use their own advantages to gradually replace it. HTML5 is also very strong, on the multi-platform, multi-screen equipment, good compatibility enables front-end engineers on a variety of platforms to show their strength. Stewed two years forward the company received is also a spa application of the project, but also quite a few of their own experience, today to write a blog, share with you.

SPA

A single-page Web application (single-page application is referred to as SPA) is a special Web application. It limits all activities to a single Web page, loading the appropriate HTML, JavaScript, and CSS only when the Web page is initialized. Once the page has been loaded, the spa will not reload or jump through the page because of user action. Instead, it uses JavaScript to dynamically transform the content of HTML to enable UI interaction with the user. The SPA provides a smoother user experience due to the avoidance of page reloading. Thanks to Ajax, we can achieve no jump refresh, but also thanks to the browser's histroy mechanism, we use the hash of the changes to achieve the driving interface changes. This simulates the single-page transition effect of the element client:

Advantages and Disadvantages

It makes sense for the spa to be sought after, but it also has its shortcomings. Of course, everything has two sides, the following is a summary of some of the current spa advantages and disadvantages:

Advantages:

1. No refresh interface, to give users experience of native application feeling

2. Save Native (Android and iOS) app development costs

3. Improve publishing efficiency without having to install the update package every time. This is especially impressive for iOS developers.

4. Easy to use other well-known platforms more conducive to marketing and promotion

5. Trends in compliance with web2.0

Disadvantages:

1. The effect and performance are quite different from the original

2. The version compatibility of each browser is different

3. Business increases with the increase of code volume, not conducive to the first screen optimization

4. Some platforms are biased against hashes, and some do not even support pushstate. (You know)

5. Not conducive to search engine crawling

Framework

A development model after the fire, the corresponding framework will follow. Like the angularjs of fire in recent years, is the most popular MVVM frame in the present, very suitable for spa, and similar to the Vuejs, stewed in the project also used, compared to the former relatively light weight. There are also early backbone that provide the most basic MVC pattern, and other module sizes and details to decide for themselves. The first contact should be ExtJS bar, this super Big Mac was used early in the creation of enterprise background applications, and now with the changes in the times to make a lot of improvements. These frameworks, libraries, and so on, are designed to better build spa applications, and their merits and demerits are not mentioned here.

Hash value

A more important concept is mentioned here: the pound sign in the URL. Actually it's just a special symbol in the browse address. Previously, we used it to locate the document location. For example, the following code:

<a href= "target" >go target</a>......<div id= "target" >i am target place</div>

Click the A link and the document will scroll to the viewable area of the DIV with the ID target. Hash In addition to this feature has another meaning: to guide the browser's behavior but not upload to the server. As you know, changing any one of the characters in the URL will cause the browser to re-request the server, except for the character after the # number. So, in short, we can understand that changing the value behind the # does not trigger the page reload, but it will be recorded in the browser history.

Implementation principle

There are a lot of ways to implement Spa, after all, a principle, the interface does not refresh. If you want to achieve the same effect as many different page transitions in your native app, we're using div toggle display and hide. While the drive Div shows the hidden way there are many kinds of

1. Listen to the change of the hash in the address bar to drive the interface

2. Record browser history with Pushsate, drive interface to send changes

3. Directly in the interface with ordinary event-driven interface changes

The first two are more common, as their change record browser is saved in the history and can be retrieved either by the fallback/forward button or by the method control in the historical object. The last method is to use the ordinary event-driven, without changing the browser's history object, so once the user presses the back button will fall back to the browser's main screen. Therefore, the first two methods are generally used. It is worth mentioning that in a browser that does not support hash monitoring and pushsate changes, you can consider using the delay function to listen to changes in the URL of the browser's address bar, thus driving the interface changes.

Start from scratch

Stewed in a long time ago, a blog post has made a small example of pushstate changes, and you can find it in the previous blog post. Here, we show how the spa works by monitoring hash changes, and starting from scratch, build a basic spa. Help you understand the simple principle of single-interface applications.

First of all, we draw three Div, they are actually as the interface of three interface, body as the Interface box container, limit their size. In order to pair each interface with a hash address, we give each div an ID, the hash address and the corresponding selector (ID, Class) to establish a link relationship, so that the value of the hash can be manipulated from the interface.

<body>  <div id= "A" class= "a j-a" >A</div>  <div id= "B" class= "b j-b" >B</div>  <div id= "C" class= "C J-c" >C</div></body>

Next, add a style to them, each div is full-screen, at first only the A interface is displayed, and the others are hidden:

    body {      height:500px;      width:100%;      margin:0;      padding:0;    }    div {      width:100%;      height:100%;      Position:absolute;      font-size:500px;      Text-align:center;      Display:none;    }    . a {        background-color:pink;        Display:block;    }    . b {      background-color:red;    }    . c {    background-color:gray;    }

Now we add behavior to the page, the first thing to know is that the hash refers to the address bar after the # Number of strings, its changes will not cause the interface refresh, but will start Onhashchange event, we have to do is to listen to this event:

function hashchanged (hashobj) {  //variable URL  var newhash = hashObj.newURL.split (' # ') [1];  The URL before the change  var oldhash = hashObj.oldURL.split (' # ') [1];  The corresponding hash is displayed and hidden  document.getElementById (oldhash). style.display = ' None ';  document.getElementById (newhash). style.display = ' block ';} Monitoring routing change window.onhashchange = hashchanged;

At present, only the above code, we can complete a simple spa, through the change in the Address bar, the interface will change accordingly. Of course, in addition to manually changing the hash in the address bar, we can also use code to change its changes, so as to promote the interface changes, the following are two ways:

As you can see, the left side is in the browser directly modify the hash caused by the interface changes, and the right is the code to control the interface changes. Both of these methods leave traces in the history, so that we can go back to the previous interface when we store the fallback/forward button. Some platforms do not allow us to manually modify the address bar (for example), then we generally use the second way. Moreover, fewer users would go to modify the address bar.

All the code is posted below:

<! DOCTYPE html>SEO optimization
Since we are dealing with a single page application, the page is not refreshed, so it will lead to our page records and content is difficult to be crawled by the search engine. Search engine Crawl page first to follow the HTTP protocol, but # is not the content within the agreement. And in fact, we have not seen search results in search engines, which record can be quickly located in a location within the page. The workaround is to use the #! number instead of the # number, because Google will crawl URLs with #!. (Google rules that if you want AJAX-generated content to be read by the browser engine, you can use "#!" in the URL (this kind of URL generally does not produce a positioning effect on the General page), so we can solve the Ajax problem of not being crawled by the search engine. In Vuejs, we can see that this is what the author did.
End
The above is a very simple spa that is implemented using the hash principle. Of course, there is still much work to be done to implement the single page application in the project. For example, the problems of the loading of the parameters, animation and asynchronous resources need to be solved. Stewed stew Here is just a simple example of the hope that the students do not want to introduce other frameworks to provide a little thought. Another single page is good, but do not mess with Oh, according to the specific needs of the project to develop a corresponding solution rather than blindly chasing tide by stream.
Resourcessearch engines will not crawl URLs with # (hash value)development of JavaScript Web rich application based on MVC
The pound sign of the URL
 How to quickly develop spa apps