前端面试之组件化|原理篇
30 秒速记
- 核心判断:虚拟节点是对界面结构的描述,渲染器通过挂载与更新把声明式描述映射为宿主环境操作
- 原理主线:围绕 「一、说一下对组件化的理解」、「二、JSX 本质是什么」、「三、JSX 和 vdom 的关系」 建立输入、状态变化与输出之间的因果关系
- 文章范围:系统讲解了前端组件化的核心概念,包括组件的封装、复用方式、JSX 的本质与解析过程,帮助读者理解组件化开发在前端面试中的重要性及其实现原理。
- 边界与代价:
key、节点类型和稳定序列决定复用边界;虚拟 DOM 解决可预测更新,不保证永远比手写 DOM 快 - 工程落地:性能分析要看实际提交次数、节点移动和组件边界,不能只用“减少 DOM 操作”解释
组件化就是把视图、数据和变化逻辑封装成独立单元,再通过 props 等明确接口实现复用。 在 React 中,JSX 只是语法糖,会被编译成虚拟节点描述;渲染时再把新旧节点映射为真实界面的挂载或更新。状态连续变化时,更新通常会被合并,避免每次修改都立即重渲染。需要注意原文的 ReactDOM.render 和 Vue 2 响应式属于历史实现,当前项目应按所用主版本判断具体链路。
这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构,再通过交互 DEMO 观察正常路径和边界路径如何改变状态;阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论,要把“历史实现”“当前行为”和“工程兼容策略”分开说明;遇到性能或架构取舍,则用实际指标、失败现象和验证手段支撑判断。
版本校准: 本文出现 Object.defineProperty、Dep、Watcher 和双端 Diff 时,主要描述 Vue 2 实现;Vue 3 使用 Proxy、effect 与新的渲染器路径。Vue 2 已于 2023-12-31 结束维护,新项目应以 Vue 3 为基线,旧项目参考 Vue 2 EOL 官方说明 制定迁移与安全策略。

# 一、说一下对组件化的理解
# 二、JSX 本质是什么
# 2.3 JSX 独立的标准
JSX是React引入的,但不是React独有的React已经将它作为一个独立标准开放,其他项目也可用React.createElement是可以自定义修改的- 说明:本身功能已经完备;和其他标准监控和扩展性没问题
# 三、JSX 和 vdom 的关系
# 3.1 为何需要 vdom
vdom是React初次推广开来的,结合JSXJSX就是模板,最终要渲染成html- 初次渲染 + 修改
state后的re-render - 正好符合
vdom的应用场景
# 3.2 React.createElement 和 h

# 3.3 何时 patch
- 初次渲染 -
ReactDOM.render(<App/>, container) - 会触发
patch(container, vnode) re-render-setState- 会触发
patch(vnode, newVnode)
# 3.4 自定义组件的解析

‘div’- 直接渲染<div>即可,vdom可以做到Input和List,是自定义组件(class),vdom默认不认识- 因此
Input和List定义的时候必须声明render函数 - 根据
props初始化实例,然后执行实例的render函数 render函数返回的还是vnode对象

# 四、说一下 React setState 的过程
# 4.1 setState 的异步

setState 为何需要异步?
- 可能会一次执行多次
setState - 你无法规定、限制用户如何使用
setState - 没必要每次
setState都重新渲染,考虑性能 - 即便是每次重新渲染,用户也看不到中间的效果
- 只看到最后的结果即可

# 4.2 vue 修改属性也是异步
- 效果、原因和
setState一样
# 4.3 setState 的过程
- 每个组件实例,都有
renderComponent方法 - 执行
renderComponent会重新执行实例的render render函数返回newVnode,然后拿到preVnode- 执行
patch(preVnode, newVnode)
# 五、React vs vue
# 5.1 两者的本质区别
- vue - 本质是 MVVM 框架,由 MVC 发展而来
- React - 本质是前端组件化框架,由后端组件化发展而来
- 但这并不妨碍他们两者都能实现相同的功能
# 5.2 看模板和组件化的区别
vue- 使用模板(最初由angular提出)React- 使用JSX- 模板语法上,我更加倾向于
JSX - 模板分离上,我更加倾向于
vue
模板的区别
模板应该和 JS 逻辑分离



组件化区别
React本身就是组件化,没有组件化就不是Reactvue也支持组件化,不过是在MVVM上的扩展- 对于组件化,我更加倾向于
React,做的彻底而清晰
# 5.3 两者共同点
- 都支持组件化
- 都是数据驱动试图
面试官追问
追问 1评审会上有人说两个框架都能写组件,所以它们的数据更新机制也必然相同;面对一个由状态变化驱动列表刷新的页面,你怎么指出这个推断的问题?
共同支持组件化和数据驱动视图,只能说明它们共享两项上层能力,不能推出内部更新机制相同。评审时应把组件边界、数据如何触发视图变化分别验证;源码未提供的调度、复用或性能结论,都不应从这两个共同点外推。
追问 2团队要把一个包含几十个业务区块的页面拆成组件,负责人只按视觉区域切分;基于“组件化”和“数据驱动视图”,你会补充哪些落地判断?
我会让每个组件对应相对清晰的业务职责与数据输入,使视图变化能由明确的数据变化驱动,而不只是把模板切成文件。拆分过细会增加协作和数据传递成本,拆分过粗又削弱复用与隔离;具体边界仍需结合页面依赖关系确定。
追问 3旧页面主要靠手动查询并修改 DOM,新框架强调数据驱动视图;迁移负责人要求一次性重写全部交互,你会怎样控制转换边界?
我会先选择状态边界清晰的区块,让数据成为视图更新的主要来源,并把旧 DOM 操作隔离在尚未迁移的区域。组件化并不自动消除新旧代码对同一节点的竞争;若两套机制同时写入一个视图,状态与页面可能失去一致性。
追问 4线上弹窗关闭后再次打开仍展示旧数据,组件本身可复用,调用方也确实更新了变量;你会怎样判断故障是否违背了“数据驱动视图”?
我会沿着数据输入到组件视图的链路检查,确认更新后的数据是否真正传入组件,以及视图是否仍被手动 DOM 修改覆盖。支持数据驱动只描述能力,不保证每个变量变化都能自动更新页面;具体响应规则和生命周期需按所用框架核对。
追问 5两个候选框架都支持组件化和数据驱动视图,架构师想仅凭这两项共同点完成选型;你会如何收窄结论?
这两项只能作为候选框架的共同基线,无法据此分出工程适配度。选型还需使用项目实际约束比较组件组织、数据更新方式及团队维护成本;当前材料没有提供更多差异,因此不能补造性能、生态或版本优劣。







