LWDW!

Learn the work from doing the work🍺

聊聊前端框架——尤雨溪
Posted on 2018-01-29

框架选择

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

组件

早期开发是以页面为单位,而现在更趋向于应用,应用则意味着组件化;而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. 跨平台复用