当前位置:Gxlcms > html代码 > 做了这么久的前端开发,听过Css模块化开发么?_html/css_WEB-ITnose

做了这么久的前端开发,听过Css模块化开发么?_html/css_WEB-ITnose

时间:2021-07-01 10:21:17 帮助过:47人阅读

说起前端模块化开发,大部分人可能只会想到js模块化开发吧,网上也确实有各种各样的js模块化方法,但是鲜有谈论Css模块化开发的吧。因为JS是编程语言,比如业内的seajs、KISSY loader等,都有很成熟的模块化规则和方案了,前端工程师可以采用模块化的方法去编写页面,打包,上线,但是CSS界却没有。

后来,CSS界出现了SASS、LESS之类的语言,这些语言的出现可以说是非常应景的,有一点很重要,拿LESS举例,less支持了模块化,你可以@import ‘xxx.less’的形式导入其他less文件(模块),方便模块化。最近因为研究Css模块化的东西,查询了许多的有关模块化的资料,也确实有所收获,今天我就来介绍一下我了解的Css模块化开发方式吧。

其实,CSS规范里面就已经提到模块化相关内容了,就是@import语法。这个语法是被当前主流浏览器(当然包括ie6)原生支持的。具体怎么用我就不再多介绍了,属于Css基础最基础的部分,如果不会的自行脑补一下吧。为啥大家很少用呢,大概是因为在生产环境单独去用@import,会有较为严重的性能问题,而且不同的浏览器以及不同的用法下也有不同的表现,比较让人郁闷。但是,这并不妨碍@import成为 CSS模块化 的利器。

也许@import诞生就是为了解决css模块化的问题吧。我们先来举一个例子看看CSS模块化的优势:

传统的开发

假如你要开发某大型网站首页,那html的head里面应该是这样引用样式的:

为了页面上比较好的性能,减少创建http请求的消耗,我们一般会选择尽量减少link的css文件数量,假如本例中,页面上所有的样式都写在了style.css里面。可想而知对于一个大型网站来讲,这个文件会有多长。如果出现bug或者想改个东西,需要的成本会比较大;而且现在业界内对于CSS开发并没有很成熟的最佳实践或者约定可循,很多时候,前端为了加快进度,可能会把某一个功能的代码放在css不同的地方,如果想去掉某个功能,肯定不敢轻易删除页面Css代码。

这时候,CSS模块化的优势就体现出来了!

模块化开发

页面不改,我们还是只引用那一个样式,style.css,但是文件内容改成如下样式:

/*xxx页面入口样式文件style.css*/

@import './css/base.css';/*页面基础样式*/

@import './css/index.css';

@import './css/header.css';

@import './css/footer.css';

……

以上为多个模块的样式文件

这里,我们把style.css中混乱的样式划分成了一个一个的子文件,作为模块。可以看到,作为示例,我把页面的一些reset样式以及一些站点公用样式放在了css目录下的base.css中,把页头拆分成header.css,把页面的基础布局都放在了index.css这个文件中,底部的样式放在了footer.css。然后相应的代码就在对应的模块中写,是不是看起来简洁、好维护很多呢?

不光是简洁,使用@import形式的模块化还有下列好处:

1. 浏览器原生支持

这点是这个工具或者这种模块化形式的亮点。对于less,想要在开发环境下方便地修改,还需要额外引入一个js文件,或者采取 less实时编译之类的方法。而采用这种 @import xxx.css文件的方法,我们可以很方便地在开发阶段,直接调试。不需要引入额外的js文件去解析style.css文件。页面中直接引入style.css文件,通过http瀑布图可以看到,base.css、index.css等被一个一个加载进来了。

2. 方便删除某个模块

这个是所有语言模块化的优势,比如哪天PD说,首页底部那个地方我想换个样式,以往,我们很多都是直接在html里面改掉原 来的class,然后在style.css里面直接加上新的样式,老的也不敢删,怕删错了,即使删了也可能会漏,因为不停的bugfix可能会导致代码乱写。而采用模块化的方案,我直接把@import ‘./css/footer.css’这一行注释掉,然后再@import新的样式,这样,即使上线了,PD说效果不好,想换回原来的,只要改一下注释,重新打包,岂不是很方便?

3. 便于管理各种日常需求

好,页面做好了,上线了,PD今天脑袋抽风,说我要加一个功能,首页右侧加一个建议反馈入口,以往,我们要打开 style.css,想想在哪儿加好,或者直接加在最后,也不管最后的地方是放什么的。采用模块化之后,我们在style.css的最后再@import ‘./css/feedback.css’即可,然后加上注释:/* 2012-12-06 PD要求加上建议反馈 */,这样以后其他修改者也能快速知道你这个模块是干神马的。

4. 方便合作开发

这也是所有语言模块化的优势。对于一个大型项目,往往共同开发一个文件,冲突的可能性非常大,很多情况下,我改了一个小地方,提交上去就冲突了,然后再花费比bugfix多10倍的时间去解决冲突,然后还不知道会不会产生另外10个新bug,而模块化,每个人负责哪些模块,职责非常明确,不容易出现问题。

5. 方便多人协作

依赖写在入口文件,而不是打包脚本的配置文件。这样开发和打包分离,新加、减少模块不需要去修改打包配置,方便多人协作。

OK,说完CSS模块化,以及如何利用@import形式来组织自己的模块,大家是不是感觉这种形式让你眼前一亮呢?但是,如果这样开发完直接上线的话,页面会有一些问题。我就挑一些比较明显的问题说一下:

1. 因为@import的文件是额外请求的,所以页面加载的时候会有一小会儿的裸体(样式没加载进来),要等这些模块一个一个加载

2. 请求数太多,页面性能不佳,对服务器压力也会相对大一些。

3. 不同的浏览器以及不同的书写形式可能会有不同的加载顺序。

所以,最好的办法就是把模块打包!这和js模块化一样的,模块化开发,然后上线之前打包,线上完美使用。

CSS Combo:CSS模块打包利器

像js打包,一般都会有配备的打包工具。对于css,很多人是用ant的concat或者grunt的concat,这样做的不利的一面就是要把css模块依赖写在打包脚本的配置文件中,很不利于维护。很多时候,你新增了模块,忘记了修改打包脚本的配置,然后发上去发现我的脚本怎么没生效?查了半天才发现是没打包进去。

如果你利用我上面介绍的@import形式来组织你的css,那么你就可以用配套打包工具CSS Combo了:

首先安装css combo:

npm install -g css-combo

然后进入你所在的入口文件(本例为style.css)目录,输入:

csscombo style.css style.combo.css

这样就会把style.css文件打包成style.combo.css文件。很简单吧。当然也可以结合gulp一起用,更方便哦。

一些最佳实践

首先,我务必要提醒大家,@import语法一定要仔细看。

@import "./css/style1.css";

这里我个人建议就用相对路径就好了,当然也支持线上和本机绝对路径,只不过想对路径有利于团队协作。

一定要注意,CSS规范中,@import必须放在其他样式之前,比如:

@import "./css/style.css";

@import "./css/style2.css";

body{

margin:0px;

padding:0px;

}

而下面这种写法:

@import "./css/style.css";

body{

margin:0px;

padding:0px;

}

@import "./css/style2.css";

mod2.css是无法被浏览器@import进来的。所以我们推荐的最佳实践就是把所有的模块import都放在入口文件的最开始,方便管理。

为啥不直接用less

团队里面不是每人都会less,也不是每个人都喜欢less。而且less不支持gbk编码,还有上面提到的,调试需要引入一段js,很多情况下,开发套页面的时候都保留了。。。其实,最根本的原因就是less和css combo解决的不是一类问题,less更多的是把css编程化,css combo只专注css模块打包。

今天就说到这里吧,有什么讲得不周到的地方,可以与我沟通。欢迎关注个人微信公众号,一起学习,一起进步,我将每天分享一篇文章,学习罗胖死磕到底。

人气教程排行