前端组件化开发实践总结

只是这些片段在数据管理方面仍然会比较麻烦，还是需要使用客户端 JavaScript 脚本，手动控制数据和 HTML 视图的同步。而对于样式，也还是存在全局污染的问题。

再后来，有些高级的开发语言，例如 Java， 推出了基于服务器的组件化开发技术，例如 JSF （JSP 的后继），基于 MVC 设计模式，通过 Java Class (POJO) 定义数据模型（Model），为 JSF 页面模板提供数据。JSF 的数据模型中有事件和生命周期相关的方法，而模板和数据模型通信的方式是 Ajax，通过使用 JSF facelets 组件的方式，可以直接发送 Ajax 请求，调用模型中的方法：

xmlns=“http://www.w3.org/1999/xhtml”

xmlns:h=“http://xmlns.jcp.org/jsf/html”

xmlns:f=“http://xmlns.jcp.org/jsf/core”

<h:commandButton id=“submit” value=“Submit”>

<f:ajax event=“click” />

</h:commandButton>

<h:outputText id=“result” value=“#{userNumberBean.response}” />

// UserNumberBean.java

@Named

@RequestScoped

public class UserNumberBean implements Serializable {

/* 其它代码省略 */

public String getResponse() {

if ((userNumber != null)

&& (userNumber.compareTo(dukesNumberBean.getRandomInt()) == 0)) {

return “Yay! You got it!”;

}

if (userNumber == null) {

return null;

} else {

return “Sorry, " + userNumber + " is incorrect.”;

}

}

}

代码来源：Jarkarta EE 官方示例

不过这种方式严格限定了编程语言，例如要用 JSF 技术就必须要使用 Java，并且样式污染的问题和客户端数据管理的问题仍然没有解决。

随着 Node.js 的普及，JavaScript 可以脱离浏览器运行了，并且带来了 npm 包管理器，基于 npm 庞大的工具链，可以 Node.js 的代码打包成浏览器中能够运行的代码。而这期间，产生了像 React、Vue 和 Angular 这样的、适合大型前端项目开发的库和框架。

React 和 Vue 目前的流行程度比较高一些，它们都是纯客户端的、组件化的 JS 库，不依赖任何后端编程语言，让程序员都能够快速上手。不过，随着项目规模的扩大，如何利用好这些库进行组件化开发，成了前端工程师必须要掌握的课题。

什么是组件

---

那么到底什么是组件呢？你想一下日常生活中，电脑上的硬件，例如显卡、内存、CPU，或者汽车的零部件：轮胎、发动机、方向盘等，这些都属于组件，它们组合起来能形成一个完整可用的产品，对于遵循了设计规范的组件，只要型号匹配，无论品牌、样式，都可以互相兼容。

我们前端工程师其实就当于是一个工厂，我们需要按照一定的规范，产生出合格的网页组件，利用它们组装成完整的页面。组件一般包含 HTML 模板、CSS 样式和 JavaScript 数据逻辑，自成一体，可以直接在其它组件中使用，组件本身的模板、样式和数据不会影响到其它组件。组件还包含一系列可配置的属性，动态的产生内容。

常见的基础组件有按钮、导航、提示框、表单输入控件、对话框、表格、列表等，我们在它们的基础上又能组合出更复杂的组件，那么对于前端中的组件的定义就非常广泛了，小到一个按钮，大到一个页面都可以形成一个组件，例如两个相似的页面，可以复用一个页面组件，只需要通过修改组件的属性，来形成一个新的页面。

为什么要组件化开发

---

你可能也知道，React 和 Vue 其实也可以完全按照传统的网页开发方式进行开发，最多是把网页大体分成几个部分，放到单独的几个文件里就好了，对于简单的网站来说没什么问题，但是如果开发的是大型的应用，例如网页版的 QQ 音乐、微信、邮箱等，它们有大量的、细小的组件，并且重复出现，这时如果针对每个页面编写 HTML 和样式，那么就会造成太多冗余代码了。

如果使用组件化的方式，我们可以把重复出现的页面内容定义成组件，这样就不用复制粘贴同样的代码了，减少代码的体积：

当某个页面内容是复合组件时，那么可以直接把基础组件直接拿过来应用：

利用这种方式，甚至可以达到 1 分钟产生一个新页面的恐怖速度，这对于你来说，节省时间去摸鱼，岂不美哉？

对于大型的公司来说，公司的网站、APP、桌面应用、Web 端应用等的设计风格都是一样的，同样的组件会在不同平台中使用，这个时候团队之间可以共享一套组件库，复用到各端平台上，减少重复开发的成本。React 和 Vue 都支持创建跨平台的应用，这时组件化开发就显得更重要了：

使用组件化开发之后，代码也容易维护了，如果页面某个部分出了问题，那么我们可以针对出现问题的组件进行修复，多次用到这个组件的地方也都会一起修复了。

最后，设计师在设计产品界面的时候，会把重复出现的 UI 也做成『组件』，这个组件的概念几乎和前端中的组件一模一样，这时可以跟设计师交流想法，看看他/她是怎么规划组件的，这样也减少了在开发时，设计规划组件的时间。

​

接下来分享一下我在组件化开发中总结的经验：

一、组件的规划

---

在正式进行前端应用开发之前，需要有充分的时间来分析，看看页面上的哪些内容需要做成组件。这一步只需要大致规划一下：

• 如果公司设计师提供了详细的设计规范，那么直接按照规范中的组件来开发就可以了。

• 如果只有设计稿，那么就看看哪些内容有 2 次或更多次在其它页面中用到了，这些大概率需要设计为组件。

• 如果连设计稿都没有，那么可以用市面上现成的组件库，例如 ant design。

• 如果没有设计稿，还要自己从零开发，那么可以根据通用的套路，把基础组件，例如按钮、菜单等，规划出来，并把可能会多次用到的页面内容，也规划出来，例如导航，底部信息、联系方式区域，这样可以只改动需要变化的部分，不影响其它部分。

这一步不用太过详细，浪费太多时间，后续开发的时候如果遇到不确定是否要写成组件的部分，可以直接把这部分代码写到大的组件里，如果其它组件又用到了，再把它抽离成组件。

二、组件代码管理

---

组件的代码应该遵循就近原则，也就是说：

• 和组件有关的 HTML、CSS 、JS 代码和图片等静态资源应该放在同一个目录下，方便引用。

• 组件里的代码应该只包括跟本组件相关的 HTML 模板、CSS 样式和 JS 数据逻辑。

• 所有的组件应放到一个统一的『组件文件夹中』。

如果组件之间有可以复用的 HTML 和 CSS，那么这个复用的部分可以直接定义成一个新的组件。

如果组件之间有可以复用的 JS 数据逻辑，那么可以把公用的数据逻辑抽离出来，放到公共的业务逻辑目录下，使用到该逻辑的组件，统一从这个目录中导入。

如果项目中使用到了全局状态管理，那么状态管理的数据应放在独立的目录里，这个目录还会存放分割好的状态片段 reducer，之后统一在 store 中合并。

对于项目中的** API 处理**，可以把它们单独放到一个文件夹里，对于同一个数据类型的操作，可以放到同一个 js 文件里，例如对 user 用户数据的增删改查，这样能尽最大可能进行复用，之后在组件里可以直接引入相关 api 进行调用。如果直接写在组件里，那么使用相同 API 的组件就会造成代码重复。

例如下面是一个组件化开发的目录结构示例（框架无关）：

project

|-- components # 所有组件

|-- Card # Card 组件

|-- index.js # Card 组件 js 代码

|-- Card.html # Card 组件 html 模板

|-- Card.css # Card 组件 css 样式

|-- icon.svg # Card 组件用到的 icon

|-- logics # 公共业务逻辑

|-- getUserInfo.js # 例如获取用户信息

|-- data # 全局状态

|-- store.js # 全局状态管理 store

|-- user.reducer.js # user reducer

|-- blogPost.reducer.js # blogPost reducer

|-- apis # 远程请求 API 业务逻辑

|-- user.js # user API

|-- blogPost.js # blogPost API

三、组件样式管理

---

在编写组件样式的时候，应只设置组件 CSS 盒子内部的样式，影响外部布局的样式要尽可能的避免，而应该由使用该组件的父组件去设置。例如，如果有一个组件设置了外边距，但是这个组件经常会用于 grid 或 flex 布局中，那么这个额外的边距会对布局造成影响，只能通过重置外边距的方式取消边距，这就不如组件不设置外边距，由父组件的布局决定它的位置，或者外边距。

类似的还有定位相关的样式，绝对定位、固定定位等对文档流有影响，应交由父组件决定，除非这个组件只有绝对定位这一种情况，例如对话框。

组件中的 CSS 要局部化，以避免影响全局样式。传统的 CSS 样式是全局的，如果有两个不同的组件，使用了相同的 class 名字，那么后定义的样式会覆盖之前定义的。一般前端库中都有定义局部样式的功能，例如通过 CSS Modules。

Button.module.css

修改子组件的样式时，优先使用选择器特异性（CSS Specificity）策略选定特定元素，而行内样式（inline-style）在设置简单样式的时候使用，尽一切可能避免 !important，因为如果再有上一层组件（爷爷组件）需要修改这个组件的样式时，就会很困难了。

四、组件属性管理

---

组件属性的命名要与它实际展示的内容相符。例如一个博客文章组件，title 属性表示标题，content 代表内容，showFullArticle 表示是否显示全文。

组件的属性应有必要的类型检查，避免在使用属性时出现异常，例如在需要数组的地方传递了布尔类型，那么如果代码有遍历数组的逻辑，就会出错。

props: {

title: String,

content: String,

showFullArticle: Boolean

}

代表事件的属性，应该和现有的 HTML 事件名称规范保持一致，以 on 开头，后面用英文表示会触发的事件，例如 onEdit 表示会触发编辑事件。

组件的属性不能直接和状态进行捆绑，而是应该只作为状态的初始值。如果把属性值作为状态值，那么就破坏了单一数据流向机制，此时该组件可以通过自身修改状态，也能通过父组件的属性变化修改状态，很容易造成数据的不一致。推荐的做法是，设置一个初始值属性，可以通过父组件传递进来，当作状态的初始值，然后丢弃，后续只通过该组件修改状态值。

const { initialTitle } = props;

const title = state(initialTitle);

// 修改

updateTitle() {

title = “…”;

}

五、组件状态管理

---

组件的状态分为全局状态和局部状态两种。

局部状态是定义在组件本身的状态，应由组件本身内部管理，当子组件需要该组件的状态值时，通过属性传递给子组件，此时状态变化时，子组件也会自动刷新。

// 父组件

const someState = state(“”);

;

当子组件需要给父组件传递状态的值时，要通过事件的方式传递给父组件，尽最大可能避免使用 ref。

// 父组件

function getStateVal(val) {

console.log(val);

}

// 子组件

状态的变化还应只通过事件或生命周期来进行，不能在其它同步执行的代码中进行，这样不会引起组件的刷新。

const someState = state();

// 错误

const state = “newState”;

// 正确

handleButtonClick() {

someState = “newState”;

}

全局状态是多个组件共享的，如果有多个组件共享某个状态，那么应该把状态定义在这些组件统一的、最接近的父组件中，或者使用全局状态管理库。

全局状态的修改，应该由类似于 actions 的行为触发，然后使用 reducer 修改状态，这样能追溯状态的变化路径，方便调试和打印日志。

// 组件

function updateState() {

emitAction(“changeState”);

}

// reducer

function someState(state, action) {

switch(action) {

“changeState”: someState => {

log(someState);

return newState

}

}

}

全局状态推荐按领域（Domain）来拆分 reducer，而不是按页面。例如按 user 用户、文章 posts、评论 comments 来拆分，而不是以 HomePage 主页、BlogPostListPage 博客列表页，BlogPostPage 博客详情页这样来拆分。这样做的好处是，能够最大限度的复用 reducer 中的逻辑。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

你要问前端开发难不难，我就得说计算机领域里常说的一句话，这句话就是『难的不会，会的不难』，对于不熟悉某领域技术的人来说，因为不了解所以产生神秘感，神秘感就会让人感觉很难，也就是『难的不会』；当学会这项技术之后，知道什么什么技术能做到什么做不到，只是做起来花多少时间的问题而已，没啥难的，所以就是『会的不难』。

我特地针对初学者整理一套前端学习资料，免费分享给大家，戳这里即可免费领取

。**

[外链图片转存中…(img-y1DjZ5tk-1713728527343)]

[外链图片转存中…(img-9KNwEJ0s-1713728527343)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

[外链图片转存中…(img-8EqLov9I-1713728527344)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

[外链图片转存中…(img-mfQEu9D2-1713728527344)]

最后

你要问前端开发难不难，我就得说计算机领域里常说的一句话，这句话就是『难的不会，会的不难』，对于不熟悉某领域技术的人来说，因为不了解所以产生神秘感，神秘感就会让人感觉很难，也就是『难的不会』；当学会这项技术之后，知道什么什么技术能做到什么做不到，只是做起来花多少时间的问题而已，没啥难的，所以就是『会的不难』。

我特地针对初学者整理一套前端学习资料，免费分享给大家，戳这里即可免费领取

[外链图片转存中…(img-xYwB5K2P-1713728527344)]