聊聊前端框架——尤雨溪
框架选择
- 结合场景需求
- 与开发者个人背景有关
- 不如让不同场景，不同开发者都变得更有效，因此多种方案并存是有益的
组件
早期开发是以页面为单位，而现在更趋向于应用，应用则意味着组件化；而React揭示了一个事实，组件树是一个函数
分类
- 接入型 container
- 展示型
- 交互型 比如各类加强版的表单组件，通常强调复用
- 功能型 比如
<router-view>，<transition>，作为一种扩展、抽象机制存在。
模版与jsx的对比
- jsx：拥有js完全的灵活度，对于功能性组件的书写远超模版
- 模版：强制性的要求在减少视图中的逻辑，以更加视图化的方式思考
collocation
相关的资源（js,css之类）以组件作切分，管理；而传统的做法是按文件类型维护
变化侦测
-
pull（粗粒度）
react与angular，需要手动告知有变化发生，之后它们会进行“暴力的”比对（react的diff，angular的脏检查），来找到哪里有变化；因此react中有
pure component一类的东西来由用户帮助系统跳过一些比对 -
push（细粒度）
由’watcher’主动告知哪里发生变动，相应的会带来额外的内存开销。因此vue2.0采用组件push，内部pull（virtual dom比对）的策略
侦测成本与自动优化的平衡取舍
状态管理
从源事件——>状态的迁移——>状态的改变——>ui的更新
e.g. 鼠标点击——>应用状态改变——>ui改变
redux与mobx与vue？
问题
- 异步的管理
- 局部状态与全局状态的管理
路由
以组件作为路由映射的基本元素
url可理解为序列化的状态
React-router4将路由去中心化，用组件本身作为路由，而非是以往的集中式管理。但这对于理解路由的结构；管理路由跳转有一些问题
web路由与应用路由区别
web路由方案，相对于应用路由，在跳转中状态被丢弃，而非是一层层的叠加状态
css方案
主流的 CSS 方案
- 跟 JS 完全解耦，靠预处理器和比如 BEM 这样的规范来保持可维护性，偏传统
- CSS Modules，依然是 CSS，但是通过编译来避免 CSS 类名的全局冲突
- 各类 CSS-in-JS 方案，React 社区为代表，比较激进
- Vue 的单文件组件 CSS，或是 Angular 的组件 CSS（写在装饰器里面），一种比较折中的方案
传统 css 的一些问题
- 作用域 —— 几种解决方案已经基本ok
- Critical CSS —— 对于服务端渲染尤为重要，因此需要在服务端侦测到页面用到了哪些css，vue可以在编译时将css插入与组件的生命周期挂钩，而css in js
- Atomic CSS（原子类）—— 优点，css体积小，不过由静态编译去进行这种处理也完全可行
- 分发复用
- 跨平台复用
原文链接:
http://b-sirius.me/2018/01/29/%E8%81%8A%E8%81%8A%E5%89%8D%E7%AB%AF%E6%A1%86%E6%9E%B6/
