兼容
pc web：比如 MA Station。基于chrome，可以手机访问（需要业务做适配）。 android 上兼容 微信浏览器 和 QQ浏览器，safari 支持 iOS > 8（safari 的版本随系统版本）。比较任性。
mobile web：比如 下单系统。主要在微信浏览器内访问。
safari 的兼容测试可以用 mac 自带的模拟器 simulator 来测试，非常方便。
bootstrap
基于老牌的 bootstrap，相对简单易用。v4 现在还在 beta 中，如果正式了还是可以考虑迁移的。或者 beta 阶段迁移。
less
因为 bootstrap3 是 less ，移动端基于所以也就用了 less， 实际上 sass 更强大。bootstrap4 也采用了 sass。等迁移到 bootstrap4 后我们也会采用 sass 的，就是这么任性。
less 函数有个特性有点奇怪，我用过，不过不具备可维护性，不建议大家用。
// 正常情况
.fun1(){
background: red;
}
.aaa{
.fun1();
}
// 一个类名也可以当函数用，不建议用
.class1{
background: red;
}
.aaa{
.class1();
}
flex
web 开发都是基于 flex 的，这给我们的布局很大的方便，非常的灵活，可以很简单的。
上面系统的整体兼容性也基本是考虑 flex 的兼容上。
要特别注意的地方是 flex-shrink 即项目的缩小比例，默认为1，即如果空间不足，该项目缩小。 但是不推荐直接操作 flex-shrink，而是用 flex: none 或者 flex: auto。
移动端高清屏1px
框架用的方法是 scale(0.5) 方法。不过多介绍，(网上文章很多)[https://juejin.im/entry/584e4...
命名
没有前缀的 btn 是 bootstrap，前缀 gm- 是 react-gm 库的。 b- 是 业务内的。(连接符-)
模块内部的命名保留模块，即
// good 长是长了点，但是可维护性可读性很强
.b-home{
.b-home-top{
background: red;
.b-home-top-btn{
background: white;
}
}
}
// bad 因为可能其他库有定义了 top 这个样式。 这样就会有被覆盖的可能性。
.b-home{
.top{
background: red;
}
}
特殊的类名除外，比如 disabled checked error in out on off 等除外。
.b-home{
.b-home-top{
.disabled{
background: gray;
}
}
}
less 变量命名同上，只是换成了骆驼峰，去掉了连接符
命名上有个出名的 BEM ，不了解，哈哈。
组合思想
目标是开发者想实现什么样式，通过 react-gm bootstrap 提供的类名来组合即可，这要求他们提供的类名足够丰富。当然这个想法已经满足了。
至于可能会出现某些场景不满足的（肯定会有），做法是
1 是否场景不合理？也可能是故意约束，克制，不提供此功能。
2 提出来讨论，共同抽象，沉淀到 react-gm 上。
3 实在特殊的就特殊处理，直接写在style上。
那组合思想是，其实 bootstrap 也是组合思想
组合思想带来的好处是
1 可读性和可维护性增强，通过 className 能想象出 UI。
2 速度快，直接写 jsx 即可。 不用来回切换 js/html css 文件。
分离css
以前 css 是通过 webpack 打包在 js 内的，这样带来的坏处是
- js 要处理这些 css，自然需要花费时间。同时还阻塞其他 js 代码的执行时间。
- 按照组合思想开发，理论上 css 会很少改动，js 确实常改动。这样 css 没法独立缓存。
- 如果有 dom 的话，会是先 dom 出来，之后加载 js 处理 css 部分。这时会看到页面没样式，突然又有样式的闪烁，不太好。理论上 css 最好释放 head 提前 load。
所以就分离了呗。
降级处理
通过 autoprefixer 来做降级，比如
// 原来
display: flex;
// 处理后
display: -webkit-box;
display: -webkit-flex;
display: flex;
细心的同学可以发现，只有 -webkit-，没有 -ms- -moz- -o-。从兼容性上来考虑，只处理 -webkit- 已足够。
css module
有短时间引入了 css module，不过现在用的很少了。 当成的目的是 css module 模块化，但是带来了一些问题
- css(less) 模块化后随 js 的引入而引入，css 即异步加载的
- 以此同时 less 并没有在主框架上，因此没法使用 变量 函数 等。
于是慢慢废弃。
随着 react-gm 提供的类名组件完善，后面真正用到 css module 的地方少之又少。 所以后面 css module 是会被废弃掉的。
react-gm.min.css
以前 react-gm 是提供 dist 文件的，即 js 和 css。这样在开发 Station 系统的时候没有问题。
但是 MA 要求换种颜色主题，那么就需要和 bootstrap 一样，提供一个 theme.css 的文件。 要抽出这 part 需要进行改造，工作量是挺大的。
后来 react-gm 废弃了 dist 形式，直接引入 src 的 index.js 和 index.less 文件。
库的 css 怎么引进来
基于上点
// ma index.js
import 'react-gm';
import './index.less'
// ma index.less 覆盖主题色变量即完成换主题
@brand-primary: #2c9feb;
// react-gm index.js
import './index.less'
// react-gm index.less
@import "less/bootstrap.less";
浮层管理
这个话题也可以说 浮层的管理。开发者越少关心 z-index 越好，组件提供了封装。 当然就需要框架考虑的东西更多了。
层级大致是
- 正常的文档流 1
- modal 1000
- tip 9999
另外 modal 衍生出来的 Dialog 形态即对话框，要求只有一个。不能出现弹窗中有弹窗。 技术上可以做到弹窗有弹窗，但克制，不提供相应的能力。
position fixed
移动端是禁用 position:fixed 的，不过多介绍 http://efe.baidu.com/blog/mob...
vm vh rem px
我个人是比较倾向于用 px 的。因为很简单，切和 pc web 的开发习惯一致，也是大家开发网页的默认单位。无须什么转换成本，上手就来。
当然如果是设计驱动的公司，要求高保真还原设计稿，就不太一样了，会考虑用 rem 方案。 基于兼容性考虑，我们可以直接用 vm vh。http://www.w3cplus.com/css/vw...
btw，个人还觉得 rem 在执行上很麻烦，也有对 rem 不了不深的原因。
毛玻璃
场景是对话框弹起来的时候背景出现毛玻璃效果。
这里的关键是 背景的 dom 和 对话框 不能是 包含关系，然后对背景 dom 做 filter:blue(2px)。 只要管理好 对话框的 dom 即可。
另外关键是，背景 dom 什么时机设置 filter，什么时候取消 filter。 于是引入了事件。 对话框 弹起 关闭都发出事件通知到 背景 dom 即可。
框架层架构
框架层采用了 flex 布局，给了指定区域做业务，业务只需也只能关心该区域，不能干扰其他区域，如需，需要讨论商量好。
业务区域做内滚动，这 part 其实不太好，后面想重构掉。 不好的地方有，1 滚动只要指定 dom 非 document.body。 2 跟随 dom 的弹窗不好做，需要计算位置。
css3
由于浏览器的环境很良好，所以可以尝试很多 css3 的特性，也不一定是 css3，大致意思是可以用上很多高级的功能。 比如 calc、filter 等。
图标
坚决不采用 img 来做图标。 采用 iconfont ，我们的字体托管在 iconfont.cn 平台。 iconfont 只能做单色，多色等不复杂的图片。如果满足不了则考虑 css3 或者 svg 方向。
