Let's look at several sites first:
Coding (https://coding.net/)
Teambition (https://www.teambition.com/)
cloud9 (https://c9.io/)
?
Note the similarities for these sites. That is, in the browser, did what was originally "should" do in the client.
Their interface transitions are very smooth, responsive, and distinctly different from traditional Web pages, what are they? This is a single page Web App.
So-called single page applications. Refers to the integration of multiple functions on a single page. Even the entire system has just one page, and all of its business functions are its sub-modules, which are attached to the main interface in a particular way.
It is a further sublimation of the Ajax technology. Ajax's no-refresh mechanism to the extreme, so as to create a smooth user experience comparable to desktop programs.
In fact, single page application we are not unfamiliar, very many people have written ExtJS project. The system implemented with it. Very natural is already a single page. Others have implemented similar things with jquery or other frameworks.
Use various JS frames. Even without frames. are capable of implementing single page applications. It's just a concept. Some frameworks apply to the development of such systems. If you use them, you can get a lot of convenience.
Development framework
ExtJS can be called the first generation of a single page application framework, which encapsulates a variety of UI components. The user mainly uses JavaScript to complete the entire front-end part, even including the layout.
As the function is added gradually, the volume of the ExtJS increases gradually. Even for the development of internal systems. Sometimes it is cumbersome, not to mention the development of such a system above the Internet.
jquery is heavily weighted by DOM operations. Its plug-in system is relatively loose. So than ExtJS this system is more suitable for the development of a single-page system in the public network, the overall solution will be relatively light and flexible.
But since jquery is primarily for upper-level operations, it lacks constraints on the organization of the Code. How to control the cohesion of each module in the event of a sharp expansion of code. It is also appropriate to generate data transfer and sharing between modules. has become a challenging thing.
In order to solve the problem of code logic when the size of single page application grows, there are many mv* frameworks. Their basic idea is to create the module hierarchy and communication mechanism in the JS layer.
There's MVC, some MVP. There are MVVM. Moreover, they almost all have a mutation in these patterns. To adapt to the characteristics of front-end development.
This type of framework contains backbone. Knockout,angularjs,avalon and so on.
Component of
These layered frameworks in the front-end drive the component of code, so-called components, in traditional web products, many other means of UI components, but in fact components are a broad concept. The high percentage of UI components in traditional Web products is due to its lack of thickness, as the proportion of client code is added, and a significant portion of the business logic is also front-end, thus creating a very large number of non-interface components.
One of the advantages of layering is that each layer has a more exclusive responsibility, which allows it to be covered by a unit test to ensure its quality.
The most vexing problem with the traditional UI layer is that the UI layer is mixed with logic, which tends to change the DOM in the callback of the remote request, when the hierarchy is introduced. These things can be tested separately, and then through the scene test to ensure the overall process.
Code Isolation
Compared with the development of traditional page-type sites, there are some points of particular concern in the process of implementing a single page application.
Look at the features of a single page application. It is more dependent on JavaScript than a page-based site, and because of the page's single page, the JavaScript code for each seed function is aggregated into the same scope, so the isolation and modularity of the code becomes very important.
In a single page application. The use of page templates is very common. Very many frameworks have specific templates built in, and some frameworks need to introduce third-party templates. This template is an interface fragment that we can analogy to a JavaScript module, which is also a type of component.
Templates also have the need for isolation. What is the problem if you do not isolate the template? Conflicts between templates exist primarily on the id attribute, assuming a template contains a fixed ID. When it is rendered in batches. Causes multiple elements of the same ID to appear in the same scope of the same page. Result in non-predicted results. So. We need to avoid using IDs in our templates, assuming there is a need for access to the DOM. Should be completed through other selectors. Suppose a single-page application is highly modular, and it is very likely that no element ID is used throughout the application.
Code Merge and onboarding policies
People's load-time tolerance for single-page systems is different from web pages, assuming that they are willing to wait for 3 seconds for the loading of the shopping page, and may be willing to wait 5-10 seconds for the first load of a single page application, but after that, the usage of the various functions should be smoother. All sub-function pages try to be successful in 1-2 seconds or they will feel the system is very slow.
From these features, we can put a lot of other public functions into the first load, in order to reduce the load per load, some sites even put all the interface and logic on the first page loading, each time the business interface switch, only generate data requests, so its response is very fast. For example, the console of Qingyun is doing this.
Usually in a single page application, do not need to like site-based products, in order to prevent file loading plug-in rendering, JS put into the HTML after loading. Because its interface is basically dynamically generated.
When switching functions, in addition to generating data requests. Also need to render the interface, this new rendering interface part is usually the interface template, where does it come from? The source is nothing more than two, an instant request that gets through Ajax like a request for data. There is also a place inside the main interface. For example, in a script tag or an invisible textarea, the latter has an advantage in switching between functions, but adds to the burden on the main page.
In a traditional page-type site, the pages are isolated from each other, so. Assume that there is reusable code between pages, usually extracted as separate files, and may need to be merged according to the requirements of each page. In a single page application, assume that the total code volume is small and can be packaged once on the home page. Assuming that the size is large enough to be loaded into execution, the granularity of loading can be larger. There are no repeated parts between the different blocks.
Management of Routing and state
Some of the online applications we saw most started, some of which were managed on the route or not.
What is the purpose of managing routing? is to reduce the user's navigation costs. Let's say we have a function. The click of the navigation menu has been experienced many times before it appears.
Suppose the user wants to share this function address to others, how can he do it?
There is no such thing as a traditional page-type product. Because it is in the page unit. Also sometimes, server-side routing handles all of this. However, in a single page application, this becomes a problem, because we only have a page, the interface of the various functional blocks are generated dynamically. So we're going to do this with the management of the routing.
The detailed approach is to divide the product function into several states, each of which maps to the corresponding route, and then dynamically parses the route to match the functional interface by pushstate this mechanism.
With routing, our single-page products are able to move back and forth, as if they were between different pages.
In fact, in addition to the Web products, have long been the management of routing technology solutions. In Adobe Flex. It will tabnavigator the analogy. Even the drop-down box is selected in the appropriate state on the URL. Because it is also a single "page" of the product model. Need to face the same problem.
When the product status is complex to a certain extent, the routing becomes very difficult to apply, because the management of the state is extremely troublesome, such as the beginning of the C9.io we demonstrated in the online IDE, it will not be able to put the status corresponding to the URL.
Cache and Local Storage
In the operating mechanism of a single page application. Caching is a very important aspect.
Because the front-end parts of such systems are almost entirely static files. So it can take advantage of the browser's caching mechanism, such as dynamically loaded interface template, but also can do some of their own definition of caching mechanism. Take the cached version number directly in the non-first request to speed up the load.
There are even scenarios in which the JavaScript code is dynamically loaded at the same time that it is cached. This basket.js, for example, Addy Osmani. The HTML5 Localstorage was used as a cache for JS and CSS files.
In a single-page product, business code often needs to deal with local storage and store some temporary data. The ability to use Localstorage or localstoragedb to simplify your business code.
Service-side communication
Traditional Web products typically use JSONP or Ajax as a way to communicate with a server, but in a single-page Web application. There is a very large part of this kind of real-time communication using WebSocket.
WebSocket has a great advantage over the traditional HTTP-based communication mechanism.
It makes it very convenient for the server to use reverse push, and the front end responds only to events that actually generate business data. Lower the meaningless Ajax polling over and over again.
Because WebSocket is only supported on more advanced browsers, some libraries offer compatibility scenarios in different browsers. Socket.io, for example, will downgrade to a browser that does not support websocket to use Ajax or JSONP, and is completely transparent and compatible with the business code.
Memory management
Traditional Web pages often do not need to be considered for memory management. Even if a memory leak occurs, the user has a relatively low dwell time. It may be very quick to flush out the page, but the single page application is different. Its users are very likely to keep it open all day. So. We need to be careful about the DOM operations, the network connections, and so on.
Planning for Styles
In a single page application. Because of the high level of integration of the page. All pages are clustered into the same scope, and the layout of the styles becomes important.
Style planning is mainly about several aspects:
Separation of datum styles
This includes browser-style resets, global font settings, basic conventions for layout, and responsive support.
Partitioning of component styles
This is a two-level plan, first of all the styles of various interface components and their child elements. Next is some cosmetic styles. Component styles should minimize interdependence, and the styles of each component agree to redundancy.
Management of stacking order
Traditional Web pages are characterized by many elements. But there are few levels, and a single page application can be a little different.
In a single-page application, you need to plan the stacking order for various UI components in advance. That is z-index, for example, we may have various popup dialogs, floating layers, which may be combined into various stacking states. The new dialog z-index needs to be taller than the old, and the talent is guaranteed to cover it. And so on, we need to plan for these possible cover-up. So, how to plan it?
Those who know the knowledge of communication should know that different frequency segments are used in different modes of communication, and that in some countries the use of airspace is divided. We can also pre-segment in the same way, and the z-index of different types of components fall into their respective intervals. To avoid their conflicts.
Product morphology for single page applications
We started by mentioning that there are a lot of new web products that are built using a single page application, but in reality, these products are not just on the web.
Open the chrome store and we'll find a lot of offline apps. These products can be regarded as the embodiment of single page application.
In addition to various browser plugins. With the Node-webkit, this shell platform. We are able to use web technology to build local applications, and the main part of the product is still a familiar single page application.
The popularity of single-page apps is gradually being added. It is assumed that some start-up internet companies are being followed. Will find that a very large part of the product model is single-page. This model can bring a smooth experience to the user during the development phase. Requires a higher level of JavaScript skill.
In the development process of single page application, the front and back end is separated by nature, and the two sides use API as the demarcation. Front end as the consumer of the service, the backend as the provider of the service. In this mode, the front end will drive the backend service.
When the backend no longer bears the template rendering, the output page works like this. It can focus more on the implementation of the provided API, in this case. The Web front end is in the same position as the various mobile terminals, and gradually makes the backend API no longer differentiated for each end.
Changes in deployment patterns
In today's era, we have been able to see the emergence of a product. That's the "no-end" web App.
What kind of thing is this? Based on this idea. Your product will probably just have to write a static web page yourself, customize the server API and cloud storage on some kind of baas (backend as a service) cloud platform, integrate the SDK provided by this platform, and interact with it through AJAX, for certification, social, message push, Real-time communication, cloud storage and other functions.
When we look at this pattern, we see that the front-end deployment is completely detached, the front-end code is completely static, which means that it can be placed on a CDN, and the access will be much faster. And the server is hosted on the Baas cloud. Developers also don't have to focus on some of the details of deployment.
Suppose you are an entrepreneur. What is being done is a real-time collaborative one-page product that enables high-speed customization of back-end services on the cloud platform. Spend most of your precious time on developing the product itself.
Flaws in a single page application
Single page application The most fundamental flaw is not conducive to SEO, because most of the interface is dynamically generated, so the search engine is not easy to index it.
The challenges posed by the single page of the product
A product wants to be single-page. The first is that it must fit into a single-page pattern.
Second, in this process. There are some changes to the development model and there are some requirements for development skills.
The developer's JavaScript skills must pass, at the same time need to understand the component, design patterns, he is not a simple page, but a browser to execute in the environment of the desktop software.
Original address: HTTPS://GITHUB.COM/XUFEI/BLOG/ISSUES/5
Build a single-page web App