聊聊前端框架——尤雨溪

框架选择

• 结合场景需求
• 与开发者个人背景有关
• 不如让不同场景，不同开发者都变得更有效，因此多种方案并存是有益的

组件

早期开发是以页面为单位，而现在更趋向于应用，应用则意味着组件化；而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 的一些问题

1. 作用域 —— 几种解决方案已经基本ok
2. Critical CSS —— 对于服务端渲染尤为重要，因此需要在服务端侦测到页面用到了哪些css，vue可以在编译时将css插入与组件的生命周期挂钩，而css in js
3. Atomic CSS（原子类）—— 优点，css体积小，不过由静态编译去进行这种处理也完全可行
4. 分发复用
5. 跨平台复用

原文链接:

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/