Front-end project structure design fine Plan

Last Update:2015-10-21 Source: Internet

Author: User

Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞

The beginning of the beginning, the front-end project is very simple, HTML outside, and then create a new CSS and JS folder, it looks very clear.

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

Too much HTML, trouble finding.
CSS and JS need to be compressed
CSS and JS need to be published to CDN
Start by simply relying on a jquery, and later found that dependent plug-ins more and more, not good update maintenance
How to implement a public header inside HTML
JS and CSS contain a lot of duplicate code, how to refactor the project
How the front end delivers code to the backend fill template code

Many companies have their own solutions to these problems, Node because the language is also JS, became the first choice for many companies.

The relevant hot frames are grunt,gulp,webpack,bower and so on.

People who are willing to read the document have used these novelties and solved a lot of front-end problems.

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

They don't know when and how to use these tools. The design of the front-end project can be very arbitrary, it is these random, so many people in the choice to start confused.

This article will provide a perfect front-end project structure planning scheme, hoping to help you in refactoring the front-end project.

A planning scenario is not just a definition of how a file is placed, how a file is named, but more importantly a tool that implements the entire process, and if there are no tools to support it, all scenarios are nonsense.

Front-end Project structure

root directory |  -Assets:  store all JS and CSS, etc., these resources may be published to CDN  |  | -Images: A background image to store all CSS styles
  |  | -Fonts: The fonts required to store all CSS styles  |  | -Styles: Store all CSS
  |  |  | -Common: Store public CSS Code  |  | -Scripts: Store all JS
  |  |  | -Common: Store common JS Code  |-Include:  store all common HTML and Kinsoku clips  |-Images:  store foreground picture and Flash |-  libs:  Third-party class libraries required for front-end  | Views:  If a backend MVC framework is used, the page is here.  |-_my:  Store the files the developer needs, this folder should be ignored by GIT and SVN.  |-page1.html Store The final front page, which is not required if the MVC framework is used.

HTML Document Structure

<!DOCTYPE HTML><HTML><Head>    <MetaCharSet= "Utf-8" />    <title>Title</title>    <!--#include virtual= "/include/header.inc" -    <Linkrel= "stylesheet"type= "Text/css"href= "Assets/styles/common/blog.css" />    <Linkrel= "stylesheet"type= "Text/css"href= "assets/styles/page2.css" /></Head><Body>    <!--#include virtual= "/include/body.inc" -content<!--#include virtual= "/include/footer.inc" -    <Scripttype= "Text/javascript"src= "Assets/scripts/common/blog.js"></Script>    <Scripttype= "Text/javascript"src= "Assets/scripts/page2.js"></Script>    <!--#include virtual= "/include/stat.inc" -</Body></HTML>

/include/header.inc:

    <Metahttp-equiv= "X-ua-compatible"content= "Ie=edge, chrome=1" />    <Metaname= "Viewport"content= "Width=device-width, initial-scale=1, Minimal-ui, maximum-scale=1, User-scalable=no" />    <Metaname= "Apple-itunes-app"content= "App-id, app-argument=">    <Metaname= "description"content="" />    <Metaname= "keywords"content="" />    <Linkrel= "Search"type= "Application/opensearchdescription+xml"href= "/opensearch.xml"title="" />    <Linkrel= "shortcut icon"href= "Favicon.ico" />    <Linkrel= "Apple-touch-icon"href= "Favicon.png">    <Linkrel= "stylesheet"type= "Text/css"href=".. /assets/styles/common/common.css " />

/include/body.inc:

Here can put some of the whole station common page header, for example need to add an emergency notice for the whole station banner, can add here.

<!-- [If Lt IE 9]><div role= "alert" > Your browser is really <strong> Mrs. wife Old </strong> don't go after school, upgrade the browser again <a target= "_blank" class= "Alert-link" href= "http://browsehappy.com" > Upgrade now </a></div><! [EndIf]  -

/include/footer.inc:

Here you can put some common public footer, such as copyright notice.

< Div > All rights reserved @copy; Xuld</div><type= "Text/javascript" src = "Assets/scripts/common/common.js" ></ Script >

/include/stat.inc:

Here you can put some website statistics code.

<!---

Other documents

If you have a public sidebar, ad position, etc. in your project, you can add additional files to the include yourself.

If a site requires a variety of different copyright notices, you can make a footer-full.inc and footer-simple.inc, and then the public include: Footer-common.inc.

Static resource Reference

If you need to use technologies such as Less/sass/coffee in your project, you can refer to these files directly. When publishing, the publishing tools do these things:

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 a CDN, the publishing tool should automatically upload the file to the CDN and change the path in the file to the CDN address.

Before release:

<rel= "stylesheet"  type= "text/css"  href= ". /assets/styles/page1.less "/>

After publishing:

<rel= "stylesheet"  type= "text/css"  href= "http:/ /cdn.com/project/assets/styles/page1.css?_=md5 "/>

Time Stamp issues

Because of the caching of static files, each release can easily cause the page to not update if the path remains unchanged. There are three types of options:

Add the _=MD5 to the path.
The update file is named Page1_md5.js
Copy to a folder named 20151021

The personal suggestion uses scenario 1, because the change quantity is small, is not easy to mistake. However, if the CDN does not support it, other options may apply.

Scripts and Styles

If the project, a person dedicated to the CSS, a person who is responsible for JS, a person dedicated to the HTML to the background code, the above folder structure is more reasonable.

If the same person is responsible for CSS and JS, it is recommended that you do not differentiate between the styles and scripts folders, placed directly in the assets directory.

If the conversion of HTML to the background code is the same person, it is recommended that CSS and JS directly in the page, the publishing tool is responsible for extracting it:

<__dest= "Assets/styles/page1.css">/   *    * *</style>

Public Code Dependencies

Each HTML page must be cited as 3 JS and 3 CSS, respectively:

Public js:common/common.js of the whole station
Js:common/blog.js common to all items (or similar pages, such as list pages, detail pages)
Page-Private Js:common/page1.js

CSS and JS are processed in the same way, and one by one corresponds.

Individual pages can introduce some external JS and CSS, such as editor.js this relatively large file. In principle, however, each file can only be cited as 5 JS and 5 css at a maximum. Files that need to be cited need to be packaged and merged.

For performance reasons, it is sometimes possible to inline the page's private JS and CSS directly into the page.

<src= "Assets/page1.js?__inline"></script>

Modular components

All reusable components, third-party frameworks are placed in Libs,Libs files are ignored when they are published, and projects cannot directly reference code under Libs.

If you need to reference a component, there are three scenarios:

A simple file contains
Modular solution based on CommonJS
Based on other modular solutions

A simple file contains

If the project is small and does not require too much modularity, the direct use of file inclusions is most convenient:

Common.js

// #include/libs/3rdlibs/jquery-2.1.0.js // #include/libs/3rdlibs/jquery.mobile.js


Common code required for other projects

The publishing tool handles #include.

CommonJS Modular Solution

var $ = require (' libs/3rdlibs/jquery ');

Once released, the CommonJs module will be converted to a standard AMD module.

Packaging issues

Suppose a page needs to refer to Common.js and page1.js, and these 2 JS refer to several components under Libs (possibly duplicates)

Then Page1.js can add the following command to exclude the files introduced by Common.js

// #exclude Common.js var $ = require (' libs/3rdlibs/jquery ');

The last generated code, Page1.js, will contain all the required modules, and the modules contained in the Common.js are removed.

Project Release and commissioning

The code scenario described above cannot be run directly in the browser, there are three scenarios where you can implement each of the features described in this article:

Perform the JS implementation of all the features described above in the browser. Advantages: Good compatibility, disadvantage: low efficiency.
Listen to the file changes, after saving the file to parse the above instructions and generate files. Advantages: Good compatibility, easy handling, disadvantages: unstable.
Custom server, this server automatically completes the build task when requested. Advantages: High efficiency and stability, disadvantage: Need to customize the server, and only used in development.

Other tools support Bitmap

It is very useful to have a bitmap that corresponds to a friend who often cuts pages.

<src= "@100x100.jpg">

Ajax Interface Simulation A.NJS:

Writejsonp ({    1});

Written in the last

This article describes a recommended approach and the functionality that a publishing tool needs to provide. Each team can make individual customizations for its own needs. The examples mentioned in this article are written in Tpack as prototypes. Different tools will have a slightly different wording. But it solves the same problem.

Front-end project structure design fine Plan

This article is an English version of an article which is originally in the Chinese language on aliyun.com and is provided for information purposes only. This website makes no representation or warranty of any kind, either expressed or implied, as to the accuracy, completeness ownership or reliability of the article or any translations thereof. If you have any concerns or complaints relating to the article, please send an email, providing a detailed description of the concern or complaint, to info-contact@alibabacloud.com. A staff member will contact you within 5 working days. Once verified, infringing content will be removed immediately.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

Get Started for Free

Sales Support

1 on 1 presale consultation

Chat Contact Sales
After-Sales Support

24/7 Technical Support 6 Free Tickets per Quarter Faster Response

Open a Ticket
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.

Learn More

Front-end project structure design fine Plan

Contact Us

A Free Trial That Lets You Build Big!

Sales Support

After-Sales Support