聊聊前端框架——尤雨溪

框架选择

• 结合场景需求
• 与开发者我的背景有关
• 不如让不一样场景，不一样开发者都变得更有效，所以多种方案并存是有益的

组件

早期开发是以页面为单位，而如今更趋向于应用，应用则意味着组件化；而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/