project thinking

A. 选型

  • css ui 库
  • css 预处理器 less || sass || stylus
  • js 工具库
  • 是否需要mvc? -> (underscore & backbone) || angularJS || emberJS [需根据开发团队熟练程度以及业务需求,而不是追求新的模式]
  • 模块化 CMD seaJS || AMD requireJS

B. 目录结构

后期改写完成再替换style script上去。

- styl
    - lib [样式库 类似 alice.css]
     - modules [自写或其他组件 例如dialog.css]
    - includes [一些页面通用样式 例如商品列表]
    - pages [下设各级目录,对应模版文件结构,每个页面一个独有的样式文件]
    - release [发布到线上的代码,一个页面对应一个css文件]
        pro: 是否需要includes内部的文件结构 类似 seller/item/lists.css 抑或使用 seller_item_lists.css这样的形式

- scrip
    - lib [js 库代码 jquery & (requireJS || seaJS)(用于组件管理)]
    - modules [组件]
    - includes [一些页面通用的逻辑代码,根据情况,下设目录,比如点击登陆显示登录框等等,以及一些无限滚动加载的逻辑代码]
    - pages [同样式文件]
    - release [同样式文件]

其实就是目录结构的合理安排、代码抽象提取拆分、组合、以及代码复用。更做细分,将通用的逻辑、样式,页面结构也提取出来[PHP CI $this->load->control('etc');].
所以,前端架构一词,理解起来也可以很简单,什么样的场合出什么样的方案。

好处:

  • 修改一个页面功能,只关注当前页面逻辑和样式,而无需考虑其他页面影响。
  • 如果发现可复用模块,分离提取出来,然后在代码压缩时合并进去,而不是通过复制粘贴

坏处:

  • 生产文件多[不过既然都是缓存,可不考虑这方面影响?]
  • 模块分离难度

###B. 代码压缩以及部署
针对PHP CI框架 通用的head模版文件内不引入样式和脚本文件。仅在 view/screen/etc.php模版顶部声明引入。

####方案一:
模版文件顶部声明所需要的样式和脚本文件[组件/模块][未压缩版]。代码发布执行对应任务脚本,将顶部的css和js文件合并打包到release目录下,并且直接修改头部的引入文件为release目录下的发布版本。例如:

1
2
3
<link rel="stylesheet" href="http://dev.abc.com/style/lib/alice.css" type="text/css" media="all" />
<link rel="stylesheet" href="http://dev.abc.com/style/modules/dialog.css" type="text/css" media="all" />
<link rel="stylesheet" href="http://dev.abc.com/style/pages/items.css" type="text/css" media="all" />

脚本执行完成后,生成的文件顶部为

1
<link rel="stylesheet" href="http://st.abc.com/style/release/seller_items.css" type="text/css" media="all" />

####方案二:
模版文件头部声明需要的release目录下的文件。通过grunt || gulp 打包压缩。
为避免watch过程中生成文件缓慢,watch只生成开发环境代码release/*.debug.js。ugplfy任务再对debug文件进行压缩。

###C. 代码规范

  • css

    • .item_title || .item-title
    • modules、includes、pages目录下的类名前缀是否需要规定[严格划分]
    • etc…
  • js

    • 通过requireJS || seaJS 已大部分规范定义
    • JQuery对象变量保存。不应该出现这样类似的代码

      1
      2
      3
      $('.items').each(function () {
      $('.items') ...
      });
    • 各类模式根据个人喜好,可面向对象式,可函数式编程,可继承,可单例,不定型,毕竟页面已做细致拆分,模块化的方式,也不会影响到他人的命名空间和眼睛。

    • 解耦 $('.J_it_looks_like_a_dog');

    • etc…

###D. modules & includes Demo
相关页面整合进这些Demo,供开发人员快速查看。

  • 当前流程弊端[大部分情况下]

    1
    接到需求 && 设计 && (已有类似实现 ? 复制粘贴 : (实现方式 && 啪啪啪));
  • 模块化 && web Demo

    1
    接到需求 && (demo列表已有类似实现 ? 引入 : (可分离 && 有必要 ? (分离提取 && 啪啪啪) : (实现方式 && 啪啪啪)));

此啪啪非彼啪啪。

参考来源: