欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  web前端

前端项目结构设计精细方案_html/css_WEB-ITnose

程序员文章站 2024-02-15 14:19:17
...
开始的开始,前端项目很简单,html放外面,然后新建一个css和js文件夹,看起来很清晰。

随着时间推进,项目变大,问题开始一一出现了:

  • html 太多,找起来麻烦
  • css 和 js 需要压缩
  • css 和 js需要发布到 CDN
  • 开始只简单依赖一个jQuery,后来发现依赖的插件越来越多,不好更新维护
  • html 里面怎么实现公共一个头
  • js和css包含大量重复代码,怎么重构项目
  • 前端如何把代码交付给后端填模板代码
  • 很多公司面对这些问题都有了自己的方案,Node 因为语言也是JS,成了很多公司的首选。

    相关的热门框架有grunt,gulp,webpack,bower等等。

    愿意读文档的人早以用上这些新奇玩意儿并且解决了大量前端问题。

    虽然工具很多,但对于很多新团队来说,如何完美地规划项目却仍然是一道坎。

    他们不知道应该在何时,如何使用这些工具。前端项目的设计可以非常随意,正是这些随意,让很多人在选择中开始迷茫。

    本文将提供一个趋于完美的前端项目结构规划方案,希望能为各位在重构前端项目时提供帮助。

    一个规划方案,并不只是定义文件怎么放,文件怎么命名,而更重要的是包含实现整个流程的工具,如果没有工具支持,所有方案都是扯淡。

    前端项目结构

    根目录  |- assets:  存放所有js和css等,这些资源可能发布到 CDN  |  |- images: 存放所有 CSS 样式需要的背景图片
    | |- fonts: 存放所有 CSS 样式需要的字体 | |- styles: 存放所有CSS
    | | |- common: 存放公共的 CSS 代码 | |- scripts: 存放所有 JS
    | | |- common: 存放公共的 JS 代码 |- include: 存放所有公共的 HTML 头尾片段 |- images: 存放前景图片和flash |- libs: 存放前端所需的第三方类库 |- views: 如果使用了后端 MVC 框架,则页面放在这里。 |- _my: 存放开发者自己需要的文件,这个文件夹应该被 GIT 和 SVN 忽略掉。 |- page1.html 存放最终的前端页面,如果使用了 MVC 框架则不需要。

    HTML 文档结构

    标题    内容        

    /include/header.inc:

        

    /include/body.inc:

    这里可以放一些全站公用的页头,比如需要为全站加一个紧急通知的 banner,可以加在这里。

            

    /include/footer.inc:

    这里可以放一些全站公用的页脚,比如版权声明之类。

    版权所有 @copy; 2015 xuld

    /include/stat.inc:

    这里可以放一些网站统计代码。


    其它文件

    如果项目里还有公共的侧边栏、广告位等,也可以自行在 include 添加其它文件。

    如果一个网站需要有多种不同版权声明,可以分别做一个 footer-full.inc 和 footer-simple.inc,然后公共包含:footer-common.inc。

    静态资源引用

    如果项目里需要使用 less/sass/coffee 等技术,则可以直接引用这些文件。发布时,发布工具完成这些事情:

    1. 编译 less/sass/coffee 文件,转换为对应的 css/js 文件。

    2. 更新 HTML 文件里的资源引用地址,引用生成好的 css/js 文件。

    3. 为这些资源文件引用地址添加时间戳。

    4. 如果项目使用了 CDN,则发布工具应该自动上传文件到 CDN,并更改文件里的路径为 CDN 的地址。

    发布前:

    发布后:

    时间戳问题

    静态文件由于存在缓存,每次发布如果保持路径不变,很容易导致页面不更新。有三种方案:

    1. 为路径加上 ?_=md5
    2. 更新文件名为 page1_md5.js
    3. 复制到名为 20151021 的文件夹

    个人建议使用方案1,因为改动量少,不易出错。但如果CDN不支持,可以采用其它方案。

    脚本和样式

    如果项目中,一个人专门负责 css,一个人专门负责 js,一个人专门负责将 html 转换为后台代码,则上述文件夹结构是比较合理的。

    如果是同一个人负责css和js,则建议不区分 styles 和 scripts 文件夹,直接放在 assets 目录。

    如果连转换html 到后台代码都是同一个人,则建议将 css 和 js 直接写在页面里,发布工具负责提取出来:

    公共代码依赖

    每个HTML页面,都必须引3个js和3个css,分别是:

  • 全站公用的 js:common/common.js
  • 全项目(或类似页面,比如列表页、详情页)公用的js:common/blog.js
  • 页面私有的js:common/page1.js
  • css 和 js处理方式一致,且一一对应。

    个别页面可以引入一些外部的js和css,比如 editor.js 这种比较大的文件。但原则上每个文件最多只能引 5个js和5个css。需要引的文件多时则需要打包合并。

    出于性能考虑,有时候可以将页面私有的js和css直接内联到页面。

            

    模块化组件

    所有可复用组件、第三方框架都放在 libs,libs 文件发布时会被忽略掉,项目里也不能直接引用 libs 下的代码。

    如果需要引用一个组件,有三种方案:

  • 简单的文件包含
  • 基于 CommonJS 模块化方案
  • 基于其它模块化方案
  • 简单的文件包含

    如果项目较小,并不需要太大模块化东西,直接使用文件包含是最方便的:

    common.js

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


    // 其它项目需要的公共代码

    发布工具会处理 #include 。

    CommonJS 模块化方案

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

    发布后,CommonJs 模块会被转换为标准的 AMD 模块。

    打包问题

    假设一个页面需要引用 common.js 和 page1.js ,而这2个js又分别引用了 libs 下的若干个组件(可能有重复)

    那么 page1.js 可以添加如下指令排除掉 common.js 所引入的文件

    // #exclude common.jsvar $ = require('libs/3rdlibs/jquery');

    最后生成的代码,page1.js 将包含所有所需的模块,并删除了 common.js 包含的模块。

    项目发布和调试

    以上所介绍的代码方案是不能直接在浏览器运行的,这里有三个方案可以实现本文所描述的各个功能:

    1. 在浏览器执行 JS 实现上文所描述的所有功能。优点:兼容性好,缺点:效率低。
    2. 监听文件改变,文件保存后就解析以上指令并生成文件。优点:兼容性好,处理方便,缺点:不稳定。
    3. 自定义服务器,这个服务器在请求时自动完成生成任务。优点:效率高且稳定,缺点:需要定制服务器,且只在开发时使用。

    其它工具支持

    占位图

    对应经常切页面的哥们,占位图是非常有用的。

    前端项目结构设计精细方案_html/css_WEB-ITnose

    Ajax 接口模拟

    a.njs:

    writeJsonp({    a: 1});

    写在最后

    本文所描述的是一种建议的做法,也是一个发布工具所需要提供的功能。每个团队可以针对自己的需求做一些个别的定制。本文所提到的示例都是以 tpack 为原型书写的。不同的工具会有稍微不同的写法。但是其解决的问题是一样的。