Front-end project structure design fine-grained solution, front-end project Structure Design

Front-end project structure design fine-grained solution, front-end project Structure Design

At the beginning, the front-end project is very simple, html is put out, and then a new css and js folder is created, which looks very clear.

As time went on, the project became larger and problems began to emerge one by one:

• Too many html files, so it is difficult to find them.
• Css and js need to be compressed
• Css and js need to be released to CDN
• At first, we simply depended on one jQuery. Later, we found that there were more and more dependent plug-ins, which were difficult to update and maintain.
• How to implement a public header in html
• JavaScript and css contain a large number of repeated code. How to refactor the project?
• How does the front end deliver the code to the back end to fill in the template code?

Many companies have their own solutions to these problems. Node has become the first choice for many companies because its language is JS.

Related popular frameworks include grunt, gulp, webpack, and bower.

People who are willing to read documents have used these novelty and solved a lot of front-end problems.

 

Although there are many tools, it is still a hurdle for many new teams to plan projects perfectly.

They don't know when and how to use these tools. The design of the front-end project can be very casual. It is precisely these casual design that makes many people confused in their selection.

 

This article will provide a perfect front-end project structure Planning solution, hoping to help you reconstruct the front-end project.

A planning scheme does not only define how files are stored, how files are named, but more importantly, it includes tools to implement the entire process. If there is no tool support, all solutions will be nonsense.

 

Front-End Project Structure

Root directory |-assets: stores all js and css resources, which may be released to CDN |-images: stores background images required by all CSS styles.
|-Fonts: stores the fonts required for all CSS styles |-styles: stores all CSS
|-Common: stores public CSS code |-scripts: stores all JS
|-Common: stores public JS Code |-include: stores all public HTML header and tail fragments |-images: stores foreground images and flash |-libs: store the third-party class libraries required by the front-end |-views: If the backend MVC framework is used, the page is placed here. |-_ My: stores the files required by developers. This folder should be ignored by GIT and SVN. |-Page1.html stores the final front-end page, which is not required if the MVC framework is used.

HTML document structure

<! DOCTYPE html> /Include/header. inc:
    <meta http-equiv="X-UA-Compatible" content="IE=edge, chrome=1" />    <meta name="viewport" content="width=device-width, initial-scale=1, minimal-ui, maximum-scale=1, user-scalable=no" />    <meta name="apple-itunes-app" content="app-id, app-argument=">    <meta name="description" content="" />    <meta name="keywords" content="" />    <link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="" />    <link rel="shortcut icon" href="favicon.ico" />    <link rel="apple-touch-icon" href="favicon.png">    <link rel="stylesheet" type="text/css" href="../assets/styles/common/common.css" />
/Include/body. inc:
Some public page headers can be put here. For example, you need to add an emergency notification banner for the whole site.
<! -- [If lt IE 9]> <div role = "alert"> your browser is really <strong> Mrs. wife is old </strong>. Don't leave school, after upgrading the browser, <a target = "_ blank" class = "alert-link" href = "http://browsehappy.com"> Upgrade now </a> </div> <! [Endif] -->
/Include/footer. inc:
Here, you can put some footer public across the site, such as the copyright statement.
<Div> copyright @ copy; 2015 xcould </div> <script type = "text/javascript" src = "assets/scripts/common. js "> </script>
/Include/stat. inc:
Here you can put some website statistics code.
<! -- Add website statistics code here -->
Other files
If there are public sidebar and AD spaces in the project, you can add other files in include.
If a website needs to have multiple different copyright claims, you can separately make a footer-full.inc and a footer-simple.inc, then public include: footer-common.inc.
Static resource reference
If the project requires less/sass/coffee and other technologies, you can directly reference these files. When publishing, the publishing tool completes these tasks:
1. Compile the less/sass/coffee file and convert it to the corresponding css/js file.
2. Update the resource reference address in the HTML file and reference the generated css/js file.
3. Add a timestamp for these resource file reference addresses.
4. If the project uses CDN, the publishing tool should automatically upload the file to CDN and change the path in the file to the CDN address.
Before release:
<link rel="stylesheet" type="text/css" href="../assets/styles/page1.less" />
After release:
<link rel="stylesheet" type="text/css" href="http://cdn.com/project/assets/styles/page1.css?_=md5" />
Timestamp Problems
Because static files are cached, the page is not updated easily if the path remains unchanged for each release. There are three solutions:
We recommend that you use solution 1 because the number of changes is small and it is not easy to make mistakes. However, if CDN does not support this function, you can use other solutions.
Scripts and styles
If one person is responsible for css, one person is responsible for js, and one person is responsible for converting html into background code, the above folder structure is reasonable.
If the same person is responsible for css and js, we recommend that you store styles and scripts folders in the assets directory without distinction.
If the html to the background code is converted to the same person, we recommend that you write css and js directly on the page. The release tool is responsible for extracting the Code:
<Style _ dest = "assets/styles/page1.css">/* CSS Code */</style>
Public Code dependency
Each HTML page must contain three JavaScript codes and three css codes:

 

 
  
Common js: common/common. js
 
  
Common js: common/blog. js shared by the entire project (or similar pages, such as list pages and details pages)
 
  
Private page js: common/page1.js

 
The css and js processing methods are consistent and one-to-one matching.
Some pages can introduce some external js and css files, such as large files such as editor. js. However, in principle, each file can only reference up to five js and Five css files. If there are many files to be cited, You need to package and merge them.
For the sake of performance, sometimes the private js and css of the page can be directly inline to the page.
<script src="assets/page1.js?__inline"></script>
Modular components
All reusable components and third-party frameworks are deployed in libs,The libs file is ignored during release, and the code under libs cannot be directly referenced in the project.
To reference a component, there are three solutions:

 

 
  
Simple File Inclusion
 
  
Modular solution based on CommonJS
 
  
Other modular Solutions

 
Simple File Inclusion
If the project is small and does not require much modularization, it is most convenient to directly use File Inclusion:
Common. js
// # Include/libs/3 rdlibs/jquery-2.1.0.js // # include/libs/3 rdlibs/jquery. mobile. js


// Public code required by other projects
The release tool processes # include.
CommonJS modular solution
var $ = require('libs/3rdlibs/jquery');
After the release, the CommonJs module will be converted to the standard AMD module.
Packaging Problems
Suppose a page needs to reference common. js and page1.js, and these two js references several components under libs respectively (which may be repeated)
The following commands can be added to page1.js to exclude the files introduced by common. js:
// #exclude common.jsvar $ = require('libs/3rdlibs/jquery');
The final generated code, page1.js will contain all the required modules and delete the modules included in common. js.
Project release and debugging
The Code solution described above cannot be run directly in the browser. Here there are three solutions to implement the functions described in this article:
Other tools support bitmap
It is very useful for bitmap workers who frequently switch pages.
The Ajax interface simulates a. njs:
writeJsonp({    a: 1});
 
Conclusion
This article describes a recommended practice and the functions required by a release tool. Each team can customize their own needs. The examples mentioned in this article are all written based on tpack. Different tools may be written in a slightly different way. However, they solve the same problem.