网站技术解决方案是什么,百度移动,关于网站建设,门户网站前期网络采集商家信息免费发布目前平台前端使用的是原生CSSBEM命名#xff0c;在多人协作的模式下#xff0c;容易出现样式冲突。为了减少这一类的问题#xff0c;提升研效#xff0c;我调研了业界上主流的7种CSS解决方案#xff0c;并将最终升级方案落地到了工程中。
样式冲突的原因
目前遇到的样式…目前平台前端使用的是原生CSSBEM命名在多人协作的模式下容易出现样式冲突。为了减少这一类的问题提升研效我调研了业界上主流的7种CSS解决方案并将最终升级方案落地到了工程中。
样式冲突的原因
目前遇到的样式冲突的原因其实根本原因还是css样式混乱使用导致的
1.多人协作样式互相污染这是项目中的主要问题。用开发规范来限定、用CR流程来保障并不可靠 2.引用大量第三方组件库组件库对CSS的使用不规范。比如bee.css中使用了大量important破坏了项目中的样式优先级rsuit是前端非常强大的表格组件库他的css文件中也有直接覆盖底层样式的写法label{ marign:2px } 3.直接使用组件库引入的css文件比如import material-icons.css如果引用顺序靠后这些文件可能会覆盖开发人员手写的样式。 4…
调研方案
CSS作为前端三剑客之一几乎是所有前端同学最先学习的样式表语言。在生产环境的项目工程中很少见到直接原生使用CSS的。但目前业界还没有通用的CSS工程化方案。这篇文章先简单介绍下7种在React/Next.js中较为流行使用CSS的方式并说说他们的优缺点。
原生 CSS
这是一种用选择器来划分css作用域的方式。
缺点
1.作用域问题 CSS样式之间会层叠覆盖需要用大量的classname来指定选择器来限定CSS的作用域范围。频繁的命名给开发人员增加不少心智负担而且容易搞错搞重复。
// pure css example
.card {/* styles */
}
.card__header {/* styles */
}
.card--focus {/* styles */
} 采用BEM规则来进行命名或许会简单些。 但在需要维护特别多样式的时候BEM还是不够用。尤其是当代码中开始大量出现!important这种破坏优先级的东西的时候。
// css with !important
.card {color: blue !important;
}
.card {color: red;
} 2.打包体积大 使用大量冗长的原生CSS可能会导致 打出来的包变大。包越大项目自然跑的就越慢。
CSS MODULES
这是一种在原生CSS的基础上通过modules也可以理解为文件来划分CSS的作用域。
首先先建一些以.module.css结尾的文件这些文件里的样式可以只针对某个组件某个module生效。这种做法在Next.js尤为常见因为CSS modules在Next.js是可以开箱即用的。
下面是一个例子在Home.module.css和other.module.css对同样的类名书写样式也不会产生冲突。
file Home.module.css
.page {color: bule;
} file other.module.css
.page {color: yellow;
} // 只会生效这里import的样式
import styles from ../styles/Home.module.css;
export default function Home(){return (// 蓝色div className{styles.page}h1 Home Page /h1div)
} 优势
1.当需要复用样式的时候不同的组件可以import同一份样式文件减少很多重复样式代码减轻打包体积 2.说到样式复用CSS modules还有个特殊的composes属性能引入别的module的css样式也能重写override。
.page {composes: className from ./shared.css
} 缺点
1.不够“程序化” CSS modules在原生CSS的基础上增加了以modules文件划分的作用域解决了作用域问题但仍逃不过在单个module内以原生的方式书写CSS。原生的CSS只能纯纯的枚举出每一条样式如果能在书写CSS的时候也支持一些程序特性岂不是更好比如最常用的循环、遍历、函数、继承…
CSS PREPROCESSOR 预处理器
Sass、Less、Stylus… 这些预处理器就是为了解决CSS不够“程序化”而诞生的。他们允许你用一种不一样的语法来写CSS之后再经过编译转化成原生CSS。
这里是一个例子
// 只需一键安装sass
$ npm install sass // 然后把原本的css后缀文件改成scss
// 就可以直接使用sass的方式来编写css啦比如变量名、循环、...file Home.module.scss$ primary-color: red;
$ font-stackHelveticabody {font: 100% $font-stack;color: $primary-color;
} 优势
1.可以用变量、继承、循环、函数、…等程序特性
缺点
1.学习成本 每种预处理器都有各自特定的语法虽然是用一种类CSS的语言来编写但总有有些差异。这意味着开发人员必须配合工具掌握新的语法。 2.样式和项目代码微微割裂 在解决完作用域、程序化问题后样式在前端项目中完完全全的独立出来了似乎少了一些联动能力。既然我们有JSX这样整合JS和HTML的合体语言为什么不能把CSS也合体进来呢
CSS IN JS
这是一种把CSS写进JS的解决方案就像把HTML写进JS后就有了JSX。这一类的库有styled components、emotion、jss、style tron、…
举个使用styled jsx的例子
import styles from ../styles/Home.module.css;export default function Home(){const [color, serColor] useState(orange);return (div className{styles.page}style jsx{h1 {// 取的是组件state可以随state变化color: ${color};}}/styleh1 Home Page /h1div)
} 优势
1.轻松能实现的程序化能力 在sass里的程序化能力CSS in JS都能做到甚至更强这种方式可以直接使用JS书写这种程序化语言也不需要额外学习成本。 2.创建动态样式 在sass里程序代码或许和样式文件是完全独立开来的。而使用CSS in JS样式和JS强绑定我们的样式能够跟着代码、跟着组件的state等特性实现动态样式特别灵活 3.不会有作用域问题 类似moduleCSS in JS的样式只会绑定在样式定义的组件内不会污染全局样式
缺点
1.CSS和JS混写代码管理困难。
UTILITY CLASSES 原子类
时下最火的新概念就是tailwindcss、windi css这些原子类CSS库能够提供大量的原子类样式帮助我们快速构建样式。
// 配置好tailwind之后
export default function Home(){return (// 在这里写上tailwind的原子类classname而不需要写样式div classNametext-5xl font-boldh1 Home Page /h1div)
} 缺点
1.需要比较麻烦的额外配置 2.打包后生成的HTML文件可读性非常非常低 3.没有任何的内置组件
优势
1.打包时能自动优化去除没有使用的css样式减轻打包产物体积。
CSS FRAMEWORK
bootstrap、bulma、这一类库既能提供特定的样式主题又有内置的组件比如bottom、cards、…等等。我个人在自己倒腾东西的时候非常喜欢用这一类框架因为实在是太方便啦这种方式在生产上几乎很少采用因为开发人员往往需要根据产品原型来绘制前端界面而不是这些框架固定的样式。另外采用这种方式也容易对线上性能造成比较大影响。
// 想使用这一类框架只用一键安装上
$ npm install bootstrap // 引入框架的样式文件
import bootstrap/dist/css/bootstrap.cssexport default function Home(){return (// 想要使用的样式都在bootstrap中用各种classname封装好啦直接调用boostrap的预留classname搞定div classNamealert alert-primaryh1 Home Page /h1div)
} 缺点
1.在只使用bootstrap来搭建组件和修改样式的话会不太方便 由于这类框架已经自带了许多预留组件而bootstrap的样式又是用classname来获取的。假设我需要频繁使用Bottom /组件却又不想在每次使用的时候都重复的写相同的classname那么就会将他们封装成CustomButtom /。这么做的话项目代码中就可能会有大量的仅仅是为了封装classname而存在的组件。 2.打包文件过大 整个bootstrap文件是直接import进来的。因此在打包时会把大量没使用到的classname也打包进来会造成打包产物较大
组件库
这是大家最熟悉的方式啦ant design、material design、t design、rebase、…
最终落地的升级方案
不同的CSS处理方式各有优劣在实际开发中可以自行选择和搭配合适的CSS处理手段。
在我目前工作中是将项目的原生CSS升级成css module less 的组合这样既能解决当前项目的核心矛盾作用域和样式污染问题又能让CSS的编写过程变得更“程序”比如使用变量、继承等特性。
没有使用css in js 是因为当前项目没有主题切换和动态样式这样场景此外css in js 会让一个组件文件变得非常冗长尤其是目前我的工作特别多复杂图表的封装仅jsx部分代码行数已经非常长再引入CSS代码容易变得更混乱。我个人也更加偏向能用独立文件区分出CSS代码的方式这样展示出更好的项目分层。
没有使用原子类的理由就更简单了配置麻烦可读性低而且对团队内每个人都有较高的学习成本不方便团队管理直接pass了。
在前端工程开发的过程中面对多人协作的场景建立标准和团队内的规范是非常重要的一个环节。尤其当前业界的前端就是没有通用标准的情况下影响项目工程稳健性的往往是缺乏规范和标准而不是开发人员的水平。在我工作的项目中最初就是因为大量人员流动大家在项目中各按各自的方式写CSS导致在一个项目中存在3种以上CSS写法非常难维护也出现了样式互相污染、互相冲突的情况所以才有了这次对CSS的调研以及对项目进行升级和改造的工作。
最后
最近还整理一份JavaScript与ES的笔记一共25个重要的知识点对每个知识点都进行了讲解和分析。能帮你快速掌握JavaScript与ES的相关知识提升工作效率。 有需要的小伙伴可以点击下方卡片领取无偿分享
