前端样式模板代码(前端设计模板)
为啥要保证前端工作需要的表格
为啥要保证前端工作需要的表格
在笔者学生时代，一直单纯地认为正则都是后端老哥的事儿，前端只要 split 一把梭就够了。万不得已的时候就网上搜几段正则代码，copy 一下也能用。
正则表达式语法表(部分)
这是维基百科上正则表达式的词条，截图只截了一屏，事实上这张正则表达式的表格两个屏幕都装不下。我第一次查的时候立马就弃了，于是很长一段时间里都在原地踏步，只会用用 ^ $ . * 这些最简单的语法。
最初见到正则表达式是在表单验证里，多少会用些 validate 的库，基本的电话 / 邮箱之类的校验都有现成的，真正自己写正则去校验输入格式的机会并不多。后来渐渐发觉正则表达式的魔力，它可以是前端工程师的一把利器。
日常琐事
1、老项目迁移，所有的 T.dom.getElementById('abc') 代码都要改成新的写法 $('#abc')
2、组件库升级，所有的 el-dialog v-model="a" 必须改成 el-dialog :visible.sync="a"
都是真实工作中的脏活累活，故事 1 中的项目有近 100 个页面，由于 T 库弃用了，不仅 T.dom.getElementById 还有 getElementByClass 等等调用都要改成 jquery 的写法。如果完全靠人肉，那是多么的苦力。
故事 2 中的组件库其实就是我们的 Element，我们原先很多项目都是 Element 1.x，要升级到 2.x，这个对话框的 breaking change 影响还挺大的，在 2.x 中通过 v-model 是无法唤起对话框的。因此要确保每个 el-dialog 都检查一遍，而模板代码里 el-dialog 的 v-model 可能不在第一个，属性多的时候还会换行，都需要火眼金睛。
聪明的读者肯定知道，靠人肉是个没有办法的办法，而且看多了也会眼花，最好还要 double check。虽然写正则表达式去找，也不能保证 100% 都覆盖，毕竟老项目里各种迷之代码都有，但正则能帮我们找出大部分，并且 replace 的时候也能避免输入错误，这样可以把精力放在 double check 上。
正则起源
正则表达式源于形式语言与自动机理论，关于形式化的内容不是本文的重点，感兴趣的朋友可以去 wiki 上查。
正则引擎的基础就是状态机，在编译原理中你一定会听说 NFA (非确定有限状态自动机) 与 DFA (确定有限状态自动机)，关于 NFA / DFA 通俗的解释可以参考这篇文章。
正则表达式最早在 Unix 中的 sed 和 grep 命令中开始普及。如果你用过 sed "s/aaa/bbb/" 的话，其实可以写正则表达式来做更复杂的文本处理。
而在编程语言中，Perl 是第一个实现正则表达式引擎的语言。目前大部分语言都使用基于 NFA 的正则引擎。
怎么学正则
笔者走了一些弯路，先在实战中写正则，不会写就查正则的语法表，渐渐地大部分语法也就都记住了，需要查表的也越来越少了。其实我觉得正确的学习方式应该先完整地看一本入门书籍，对整体有宏观把控后，再在实战中反复练习和查表，回头再重新看书，这样的记忆应该最深。
如果你还在为正则表达式的语法而健忘的话，推荐一本《正则表达式必知必会》，这本书只有100 页，一个周末就能看完。以后再查语法表的时候，就会越来越有规律可循。
正则表达式的语法大致可分为这几大类：
匹配字符
匹配位置
重复与贪婪
分组与捕获
前后断言
本文并不介绍正则表达式语法，只通过实际工作的例子来说明正则的运用场景。可以先根据以上几个分类，在正则表达式的语法表里再过一遍。
1、URL里的暗号
在公司的开发环境中，一般都会有两套以上的测试环境，如 alpha 和 beta 环境。而在前端页面，我们通常使用不同的 URL 来区分，例如 jack.alpha.domain.com 与 jack.beta.domain.com 分别对应 alpha 和 beta 环境，而 jack.domain.com 则是生产环境。问题来了，前端代码是同一份，它需要根据当前 hostname 所属的环境来调用不同环境的接口。
当然这个问题也是 split 一把梭就能解决的，但这并不优雅。回到正则表达式上，我们先分析需求，假设公司一级域名只有 domain.com 的，那么这个问题就是提取 appid (例子中的 jack) 与 .domain.com 中间的部分。
var reg = /\w+\.(\w+\.)?domain.com/;
var match = 'jack.alpha.domain.com'.match(reg);
console.log(match[1]); // alpha.
如上代码的正则表达式中，关键是 (\w+\.)? 这段，它表示匹配零次或一次，并且小括号是分组，可在 match 的结果中直接拿到分组捕获到的内容。
补充 1：分组里拿到的结果是 alpha.，多了个 . 不走心，怎么把它去掉呢？可以改成 ((\w+)\.)? 这样 alpha 就要在第 2 组捕获里拿到了，因为第 1 组仍是 alpha.。
补充 2：试试 (?:(\w+)\.)? 这里 (?:) 表示不产生分组号，于是仍可在第 1 组捕获中拿到 alpha。
补充 3：\w 匹配字母数字和下划线，如果你的 hostname 中包含其他字符，比如扩充成 [\w-] 就可以包含中划线 -。
补充 4：假如公司的一级域名有多个，那也可以对 domain.com 再进行扩充。
...前端模板渲染html,jquery的html,各有什么区别?
简单来说
后端渲染html 叫吐或者喷，机器人可以看到完整的呈现源码
前端模板渲染html叫填，机器人看不到完整的呈现源码
所有的渲染最终浏览都是一个html页面+js,差别就是在于后端渲染的很多都是会生成些冗余的垃圾代码(目前很对都是),前端比较好控制
前端工作流节点的使用技巧
一般网站往往架构在后端MVC框架中，由后端程序猿做主导，所以：
1、前端程序猿要对后端MVC框架有基本的了解，尤其是MVC中的V。
2、懂得V之后，就要掌握模板引擎的规则。前端模板引擎跟后端模板引擎很相似，做一些字符替换就可以将前端引擎的代码段改成后端引擎的。
我在参考了一些简单项目的前端工作流之后，搞了这么一个简单的前端工作流。
1、保证工作目录、开发目录和上线目录的内容尽可能的简单。因为html/tpl/js/css是最常编辑的文件，而内容图片、API很少修改，库、字体更是不会修改，所以都应该择出来。
2、img文件夹内存放内容图片，它不用编辑，所以择出来。但是注意，它需要一个监视器来监视文件的添加，一旦有添加，就自动压缩体积，然后覆盖源图。
3、libs文件夹的定位是：存放js库和css库以及字体库。
4、api文件夹的定位是：开发的时候使用，上线不用，所以单独存放。
5、media文件夹：存放视频和音频。如果你确定你的项目绝没有可能用到音频和视频，那么这个文件夹可以取消。
如何实现前端模块化开发
前端如果想做模块化开发，首先需要针对每一种资源（
JavaScript
、
CSS
、模板等）寻找
一种模块与集成方案，然后需要根据情况的不同选用不同的工具框架拼凑出来。
SeaJS
是一个适用于
Web
浏览器端的模块加载器。使用
SeaJS
，可以更好地组织
JavaScript
代码。
不知道别人怎么做的，我自己现在的做法是，基本通用的功能做成一个
js
文件，
js
生
成
html
标签和
style
样式，只需要一个
div
带上
id
调用一下就
ok
了，比如图片上传。而一
些常用但不通用的功能做成一组文件，包括
js
和一定的
html
结构还有一个
css
文件，也可
能还有图片什么的，有时候甚至做成不用调用，直接加载就能用。
至于具体的调用方法，
大概就是
window
定义一个变量，
放入调用的这个功能的
function
初始化一个模块，
并返回这个模块闭包中的一些方法用来操作或者获取和设置一些模块闭包
内的变量。
JavaScript
目前比较拿的出手的，也就是
JavaScript
的模块化，比如
AMD
或者
CMD
等等，分别可以使
用
RequireJS
和
SeaJS
。
去年在研究基于
Backbone
的框架
Marionette
时，想与
Sea.js
结合使用。现在来看这种组合
是完全没有必要的。
Marionette
提供了模块化的组织方案，反而生拉硬扯在一起，冲突得很
难受。其实把
JavaScript
文件一列放在
HTML
中也没什么问题。
究竟使用什么来实现
JavaScript
，
往往与选择的
JavaScript
框架有关，
选
Backbone
可以
AMD
，
也可以
CMD
。选
AngularJS
直接引用就行。
CSS
CSS
模块化应该是两方面的问题——
一是模块必须有一套基础样式。与
JavaScript
相比，
CSS
冲突简直是家常便饭，
Shadow DOM
还没成熟，
原生的
CSS
样式隔离还在路上。
所以必须有一套基础样式来规定这一套模块化组
件的样式。我们可以选
Bootstrap
，如果闲它太重，也可以自己写。
其次，每个组件必须有命名空间，避免组件间样式冲突。如果选择使用
LESS
、
SASS
等，那
就比较好办，它们的缩进语法避免写很多重复的
CSS
代码。
HTML
模板
如果使用
AngularJS
，
那
AngularJS
已经帮您解决了模板模块化的问题，
AngularJS
可以根据模
块代码中的引用加载对应的
HTML
。如果使用
Backbone
，可以选择各种各样的模板引擎，
Mustache
？不过比起
AngularJS
就低端些，我们必须自己处理模板文件，要么通过模块加载
器通过
XHR
请求，然后动态编译；或者将
Mustache
编译成
JS
，在当做模块加载。
图片、字体？
放在使用他们的模块中，该怎么引用就怎么引用。
国际化文件？这些就不多说了，总之，每种文件需要选定一种开发的组织方式。
模块分发
模块采用统一的模式来开发之后，只需选定一种包的分发方式就行了——
Bower
。
npm
不适
合这样的场景，
npm
的版本管理太过细致了。如果同一个项目中允许出现同一模块的不同
版本，事情就做的太过复杂了。
发布上线
发布上线必须一个以终为始的过程。
如果你不追求网站或者应用的速度，
那就把那些开发文
件直接丢到生产服务器上去吧。别说，我还真见过这样的商用的网站。
如果讲究一些方案，
资源合并成数个文件，
代码线上组合和运行方式完全可以与本地开发不
一样。只需要功能在就行。
JavaScript
代码打成一个文件，或者两个？都行。如果使用
RequireJS
，那
RequireJS
提供了打
包的工具，打包成几个文件，什么粒度，都行。如果是
Sea.js
也有对应的工具。就算文件都
是一个一个列出来，我们也总是可以打出来你想要的文件。
CSS
等等其他资源都是如此，就算开发时各自不同的结构模式，打包时都是可以打的。
至于上线
CDN
，版本号缓存什么的并不在本文的讨论范围之内。
总结
前端模块没有什么特效药。唯一要遵守的原则就是，
比起
Node.js
来讲，每种资源必须要
有一种自己的开发和上线组织方式
（
Node.js
开发和上线都是一致的）
，开发和上线完全可
以是两种方式，
大可不必人云亦云，
只要适合可以随意组合；
CSS
在
CSS Scoped Style
正式使
用之前，应该有一套基础样式和沙盒（模块样式命名空间）
。
每个模块中的
HTML
怎么办，
如果我们使用的框架是
Backbone
，
注定我们要将
HTML
模板转
换成
JavaScript
模块，或者使用模块加载器的插件来实现。如果我们使用
AngularJS
，那倒是
可以交由
AngularJS
。发布时
Backbone
中的模块使用
AMD
打包，
AngularJS
可以使用
Grunt
内联到页面中。
HTML
模块也没有固定的模式，没有固定的
SDK
来解脱我们。我们只能组合现有的工具！
CSS
就更不用说了，分开写，使用
LESS
、
SASS
来组织？再一次没有固定的模式没有
SDK
。