A framework for quickly building an app interface ('? ') )-----Salutjs

Objective

Stewed at the start of the company is an app app. The front-end technology uses backbone+zepto and other small JS class library. At the beginning of project development, these small and medium-sized projects use these two libraries to meet basic requirements. However, as the iterations are updated and the business grows, piles of code are overwritten into the project, making such a technical architectural approach abnormally bloated, and many interfaces becoming unusually difficult to maintain, so the stew intends to refactor the company's front-end architecture.

The idea is: the use of asynchronous module loading mode, the different menus into the interface into a number of module files, the advantage is to load the interface according to demand, and each interface is a separate module, easy to maintain and independent development. So the stew took about one months to reconstruct the front end. That is, from then on, the framework of backbone is built into a set of configuration frameworks. In this way, the project has been improved, become easier to maintain, stewed also from its learned a number of experience, accumulated some useful code, finally gradually improved, in the practice of testing (with this framework to complete the other two small and medium-sized projects), organized into a set of their own small frame out, stewed it named Salutjs. It has just been born, it is not how mature, the document is written relatively sloppy, specifically to see the development of examples, the stew on GitHub on the go up. Stewed with it has done three items, but the overall feeling is relatively good, it is very suitable for such a similar app for small and medium-sized single page applications. This blog post is to share some of the experience and framework knowledge of the stew, hoping to help gentlemen some small help in the most similar web applications without knowing how.

Architecture Ideas

As said before, as the business and interface increases, code back becomes more and more difficult to maintain. When confronted with such problems, the first thing that comes to mind is a word "divide". But how to divide it? The problem was stewed for a long time. The development of brine cooking, a line of food items, it contains the following functions: ordering, membership center, concessions, bargaining, call and so on more than 10, these functions inside, each function inside there will be related to a number of interfaces. As you can imagine, if you put all the interface business code inside a file, the whole project becomes abnormally bloated and finally dashed. The consideration is to put the code inside each of the various interfaces into the same JS, so that when the user to use one of the functions only need to load a JS instead of more than 10 interface code. When we need to switch from the interface of a function to the interface inside another function module, we use Requirejs's asynchronous loading method to load the files that need to be loaded asynchronously. This solves the problem of code coupling and bloat. It is worth mentioning that the principles of our interface are based on business requirements. Stew For example: in a la carte function there are several interfaces, but a la carte function does not necessarily require a membership card function interface, so, we write a la carte function files, is not required to put the membership card interface business included in.

HTML templates

In the rendering function, the stew did not change, followed by the underscore template method rendering. Because the interface business has been separated, the HTML structure can also be separated. It is not necessary to put unnecessary HTML code in our principal file at the outset. Stewed the principle of loading HTML templates is the same as JS, the method is to use Ajax to speak HTML as a text download, and then render to the interface. In the Require, we will go to the server to pull the corresponding template file, that is, we implement different large functions between the jump needs to request two files, one is Xx.js, the other is xx.html. In the actual development process, you do not need to call these files yourself, using the Route.mynavigate method, the framework will automatically help you to download JS and HTML files:

Directory structure

When using Salut, you need to create a file structure in accordance with some of the established directory rules. Our project is broadly divided into several categories:

construction: Config file with portal file

CSS: Style files

fonts: Font file

img: Storage Path

JS: Store all infrastructure JS and business code as well as template files

node: Run the test project node file (ignore it in real development)

page_main.html: Theme HTML file

run.js: Node file, run to get the project running

JS folder under a number of folders, stored a different JS file

base: Core code of Salut

Core: lower-level code such as backbone and Zepto

plugins: several plugins

TPL: Template file

use: Business code files for each feature

config: configuration file

map.html: The map file that needs to be used

Entrance:

Page_main.html is the entire project HTML, if there is no other special business needs, all the single page is implemented in this HTML, there will be no URL jump. Its outermost layer is a div-wrapped, as the outermost container. And then the entry JS file that was introduced with require:

<body><!--outermost container--><div id= "PageWindow" ></div><!--introducing require loading the entry file--><script Data-main= "Construction/app" src= "Construction/require.js" ></script></body>

We see that as soon as the interface starts to load and then begins to introduce the App.js file, in App.js, we will judge the current interface address, configure the default configuration of the require, introduce a custom configuration, and start pulling the corresponding interface business code down:

Naming rules

Salut naming has its own set of rules: mainly in the name of the file: the name of the business file with the beginning of the letter, and in the name of the HTML file rules are TP plus lowercase letter of the corresponding JS business file. When you register a route for each program, the name of the route begins with a capital letter, and the interface name starts with a lowercase letter, but the name is the same. Each time you create a new function, you must go to config to configure the function module file name and the corresponding interface name in the relationship, in the GitHub example you will see. The reason for this is that JS does not have the ability to read local files, so you have to write the interface in the other function files in the configuration file, so that when the need to load another interface, you know we need to load which JS.

Routing rules

Salut does not change the backbone routing rules, it follows the previous hash method, in the backbone source code, you can see there are many ways to implement the route-driven events, they are hash, pushstate, and timing functions. Salut's original intention is also sub-interface, each route corresponds to each interface, in the address bar to change the hash value (#号后面那部分, corresponding to different interfaces) to jump to different interfaces. This stew has already been mentioned in the previous blog post, and it is no longer mentioned here. The name of the route is related to the name of the interface module, which we have already mentioned in the naming convention.

Summarize

Salut is perfect for building apps similar to those mentioned above, and very simple. It is suitable for small to medium-sized app applications. After learning the rules almost as long as the simple configuration can be completed to join an interface to the project work. Stewed oneself Consider the follow-up requirejs such a template loading file replaced (already finished), finally backbone the bottom frame also change, he made a set of completely independent JS frame. But it's a long way off. The stew has uploaded the relevant documents to GitHub with a full set of demos and notes written in more detail. Gentlemen if you are interested, please take a look. The Sea of the rivers, the capacity is large. Saultjs as a newborn set of light frame has more or less problems, but also because of his practical experience is not much, it is required to continue in practice in the continuous improvement. Of course, by virtue of the strength of a person to boil, it is insignificant, for this purpose, it is open-source, hope that the gentlemen for it, make it more powerful. Or you can provide your own opinion, and you are very welcome to contribute code. In short, the stew here is not to promote their own framework, just share some of the work summed up some of the code tools. If you have any questions, please send an email to [email protected] or leave your comments in the blog comment area, and you will be back in time after the stew is seen.

Well..... 1:30 A.M. Finish Writing, gentlemen can see here to a recommendation.

Salutjs's GitHub Address

A framework for quickly building an app interface ('? ') )-----Salutjs