事情的开始是这样的
项目要重构UI,然而老孟的css功力很浅很浅,对sass更是一知半解。学习机会来了~~
情况不妙
原项目是用ionic搞得,框架本身提供了茫茫多的sass变量提供给开发者进行自定义主题,长下面这样:
ionicsass.png梳理了一下老代码发现事情没那么简单,主要问题如下:
- 原开发者丝毫不理会官方方案,所有主题相关的样式均使用高权重选择器强硬覆盖。
- 所有主题样式全挤在app.scss一个文件里。
- pages各玩各的,缺乏通用样式,冗余代码太多。
- 老员工们并不怎么会ng,没有拥抱组件化,通用组件~~零
规范的推进势在必行......
出于上述问题,修改官方提供的改变量方式可以扔一边了~~我的方案如下:
- 少覆盖多扩展,绕开问题1的坑。
- 制定规范防止问题2,问题3恶化。
- 至于问题4,放弃吧。想解决这个问题需要对其他员工进行培训,成本太高。介于公司性质和洒家的江湖地位,这事儿别想了。
关于方案1
其实方案1并不合理,但我一己之力难以改变其他组员的错误使用方式,这是一种将错就错的妥协。关于此事儿我一句也不想提。
关于方案2
所谓难者不会,会者不难。对不起,我是难者。(;´д`)ゞ全写在app.scss显然不靠谱。老孟坚信好的项目是结构美丽的。谷歌一下如何布置sass的结构,推荐下面这篇影响力较大的文章,其他优秀文章不一一列举了。
https://www.sitepoint.com/architecture-sass-project
说得很细,由于ng本身的组件化特性,就没必要搞得像文中那么复杂了。暂定结构如下:
//main.scss单纯作为入口,引入所有文件。
// Modules and Variables
@import './modules/_all.scss';
//Base
@import "./base/_layout.scss";
//Cover
@import "./cover/footer"
解释一下:
-
modules文件夹放变量和函数们,简化写法,易于迭代。
-
base文件夹存放通用的碎片样式。比如居中之类的非业务性的写法。
-
cover是对ionic提供的组件的覆盖与扩展。其实叫components更合适,但angular对component的‘私有’样式另有写法,结合目前的状况(看问题一),干脆叫cover了。
剩下的工作就是往上搬砖了。
做个总结吧:
纯主观看法:
- 不做一票儿买卖,写一步想两步,考虑日后的迭代和扩展。
- 适度抽象,sass有变量和各种继承写法,纯css可以用属性和类名控制(我对此也没啥经验,说这话有点虚)。
- 业务是业务,组件是组件,框架是框架。分开管理别抱团。
- 勤看官网少吃亏!经验主义不可取。
硬广结尾:
这个官网不是我做的...
网友评论