容器：从另一个角度看前端
分享讨论内容：
- 前端概念△
- 组件/容器△△△
- 前端的对接△△
- 前端用户△△△
场白：
公司业务量阶梯式增长，项目增多，带来的重复工作也越来越庞大，为了解决这个痛点，有了标准化、插件化等项目/概念。
目的都是把公共的地方提炼出来，作抽象、封装，达到可复用、量化、高效等目的。
我们现在做的标准项目中涉及到的容器概念就是一种抽象：xxx + xxxx = 容器。
image.png
一、前端概念△
算法 + 数据结构 = 程序
1、DOM
结构层，页面的骨架。
Document Object Model（文档对象模型）
2、CSS
页面的颜料。
Cascading Style Sheets（层叠样式表）
image.png
3、Javascript
算法层
image.png
主要用于编写不止于Web浏览器、IOS/Android、小程序等客户端/多端页面，也可以在服务端编写接口。
二、组件/容器△△△
在浏览器中，DOM是以树的结构存在的，在现代前端开发中，把一切DOM元素（用户界面看到的小至一个字符串）都可以看成是一个组件。
前端模块、插件化开发，就是基于这个概念进行的。
１、容器
有边界的，都可以理解为容器！？
image.png
概念互通：
- meta：容器上看到的，都是属于元数据。
- address：对这个容器而言，会提供一个
tag/id/className等DOM API来表明这个元素在整个DOM树上的位置，这个位置就是address。
2、AST
抽象语法树
前端的技术演进中，从jsonp-Jquery-Vue/React/angular，我觉得最好的抽象就是虚拟DOM的概念。
虚拟DOM就是通过利用AST生成虚拟节点，再通过对应API，diff后生成真实的DOM树。
提炼思维：突破传统思维，创造力转为生产力。
工程师的齿轮
3、封装
封装的容器：透明、自适应、自检查
回到业务、代码，除了download下来的，我们日常开发过程会逐渐沉淀出一些属于自己或公司内部的util、组件。
我个人的理解，针对这部分代码去抽离、封装的过程，其实也是对这部分代码涉及的逻辑定义边界，定了边界，自然就成为“容器”，有了赋能。
image.png
4、抽象的核心
让用户更少的付出，得到更优雅的回报。
image.png
三、前端的对接△△
从产品在客户那里接收到需求，到用户得到想要的界面的过程
自身
最重要的是自检，对项目负责、对他人负责、对自己的代码负责。
1、与产品
需求的backlog、变更、进度、验收
2、与UI/UX
原型、需求复对、高保真、前端实现、验收
3、与后端
- 需求同步
- 前后端对接更重要的是遵循一定的协同规范：比如
Restful风格API - 比如前端/后端实现某些数据逻辑的时候有一定困难，对应另一端是否有更好的实现
- ...
协同规范可以有效减少需求外的沟通成本 。
4、与测试
- 需求同步
- 交互同步
- 掌握更全面的bug排查方法，减少沟通成本
- ...
前端是除产品外对外感知最多的岗位，而且是技术岗位。
在沟通上，最大感受就是提问题尽量不要用反问句。
四、前端的用户△△△
前端的用户分为开发者和客户端用户。
1、开发者
代码
对于开发者而言，但凡能看到自己写的代码的， 都是自己的用户。
所以换位思考一下，对于自己编写的代码程序，尽可能满足几个前提：
- 语义化
- 简洁高效
- 责任分明
- 健壮△△△
- 注释△△
- 可增量维护
image.png
封装后的代码示例
2、客户端用户
主要是用户体验
- 首屏△△△
- 视觉
- 交互
- ...
前端最终的用户就是客户端用户，客户就是一切。
让用户更专注
===========================================================
前端做的事情：让客户端用户更优雅的偷懒
Thank you !
============================================================
