大前端时代，UI 设计师也需要学习框架！

前端设计人员的工作是创建 HTML、CSS 和展示内容的 JavaScript 代码，为 Web 产品打造用户界面。在我看来，前端设计是一座将设计与开发工作连接起来的桥梁。

当然，这一岗位的名称也不一定就是“前端设计师”。公司里负责这一任务的职位有很多种叫法，比如说：

• UI 开发人员

• 客户端开发人员

• UI 工程师

• 设计工程师

• 前端架构师

• 设计师/开发人员

• 原型工程师

• 创意工程师

• 开发设计师（Devigner，微软的发明）

不管这些人顶着的是什么名头，他们的职责都是为网站用户界面编写代码。前端设计人员的日常工作包括：

• 制作语义 HTML 标记。重点关注可访问性，为浏览器、辅助技术、搜索引擎等使用 HTML 的环境提供友好的体验。

• 创建 CSS 代码。塑造 Web 体验，处理颜色、排版、响应式布局、动画等可视 UI 元素。前端设计人员要构建的是弹性化的 CSS 代码，具备模块化、灵活性、兼容性和可扩展等属性。

• 编写主要用于操作 DOM 中对象的 JavaScript。例如在单击折叠面板标题时打开或关闭折叠面板，或者关闭一个导航面板等。

• 进行跨浏览器和设备的测试。确保 UI 在桌面 PC、智能手机、平板电脑等支持 Web 的设备（甚至未来可能出现的联网设备）上都能赏心悦目、正常工作。

• 优化前端代码的性能。创建轻量级、快速加载、流畅无卡顿的体验。

• 与设计师协作。将品牌、设计愿景和用户体验的最佳实践正确地在浏览器中展示出来。要注意的是，浏览器才是实际用户使用你的实际产品的现实场景所在。

• 与后端和应用程序开发人员合作。确保前端代码与后端代码、服务、API 等技术架构正常兼容。

看完这段总结，你可能会吐槽说作者在扯什么废话。但我之所以要阐明这些职责是要强调：这是一项艰苦且细致入微的工作，需要大量的思考、责任心和关注度。前端设计是一项全职工作，需要当作一个专业岗位来认真对待。

或者你也可能在看完这段总结后想到：“这不是前端开发人员要干的事情吗”嘛，也许就是这回事。一篇题为“大分工”的文章是这样总结的：“前端开发”这个词的涵义现在非常广泛了，因为“JavaScript 能做的事情变多了”。

“大分工”文中的图片，其中 CSS 连接着“前端的前台”与“前端的后台”两大部分

“前端开发”现在包含了一大堆内容。以前我还开玩笑说，我们前端设计人员是呆在“前端的前台”，还有很多开发人员是在“前端的后台”。这种分法挺切合实际的，因为这种大分工直接影响了 React 这样的 JavaScript 框架。

迷失在 React 中的前端设计师

React 的网站的欢迎页面是这样介绍自己的：“用于构建用户界面的 JavaScript 库”。

正好，我就是负责构建用户界面的！这可就是我的专长了，而且我专业打造用户界面已经有十多年，React 应该是我的地盘才对。

然而它并不是。或者至少对于我前端设计师的工作来说 React 没啥用。

Dan Abramov 在他的文章“UI设计的元素”中阐述了他在构建大规模应用程序的 UI 时面临的许多挑战。我觉得这篇帖子文章精准地指出了“前端的后台”和“前端的前台”之间的分界线。文章提到的内容看起来都很关键，但我承认有很多部分其实我也没看懂。他提到了保持数据同步、缓存失效、状态管理、处理路由差异等一堆注意事项，幸好我的工作从来不涉及这些内容，将来我也不想碰它们。

像 React 这样的 JS 框架的流行并不是偶然产物。这些框架为开发人员构建大型应用程序时的实际需求提供了解决方案。我很高兴这些框架可以帮助这些应用程序开发人员处理那些问题。

但是这些解决方案也有副作用，那就是侵占了 HTML 和 CSS 的空间。前端 Web 开发中 HTML 和 CSS 负责的部分被塞进了一个 JavaScript“箱子”。这可是给前端设计师打了一颗难对付的曲线球。

之前的一篇文章中我分享了自己学习React的艰难经历，并收获了许多人热情的帮助意见。但我也收到了很多像我一样困惑的人们的（通常是私人的）信件，现在都还没停。作为佐证，最近伟大的 Jonathan Snook（我一直以来的偶像，他的经历比我丰富的多）写了一篇文章分享了他自己学习 React 的痛苦历程：

我哪像是开发老手啊，简直像个大三学生似的。我经常茶饭不思就是为了搞清楚某些内容，结果越学越难受。有时我研究一两天时间都没取得任何进展，然后只能去找人给我讲课；本来讲的内容我应该自己搞明白才对，显得我很没用的样子。

看起来前端设计师们都卡在 React 上了，所以我觉得这里有些内容应该探讨一番。

组件大乱炖

React 中的一切都是组件。用户在屏幕上看到的一个按钮是一个组件；处理单击该按钮时发生事件的业务逻辑是一个组件；单击应用程序时，应用程序引导用户的路径是一个组件；从头到脚都是组件。

这些单拿出来都不是问题，但是当我们看到一个包含一大堆组件的应用程序时感到不知所措也是正常的，因为这些组件的功能天差地别，开发者还得一点点把它们捋顺才行。再次引用 Jonathan 的言论：

这些东西就那么一下子涌进来了，一开始很难分清谁是属于谁的。“噢原来这个是 Redux，那个是 React，还有一个是 lodash，总算明白了。”

我们要处理的不只是 React，还有它的小伙伴们。

我现在的工作涉及多个 React 代码库，这些代码库包括业务逻辑、展示代码、数据操作代码等让人头疼的形式，（在我看来）它们纠缠在一起装在不透明的文件结构中。睁大眼睛找一找的话可能会找到一些 HTML，当然这些 HTML 是负责实现的，但无疑是淹没在其他内容中了。

我承认我感到非常失败，直到我看到 Dan Abramov 的文章“展示组件和容器组件”时才看到了一丝希望。Dan 谈到了展示组件（沉默组件）和容器组件（智能组件）之间的差异。这篇文章总算让我感觉自己在这个疯狂的 JS 世界中可能还有那么一点立足之地的。

我研究一个基于 React 的客户端项目已经有大约一年半了，我很高兴能走上这条由这位前端设计师在全新的 JS 世界中开辟出来的道路，也很高兴能向大家分享我的旅途经历。

全新 JS 世界中的前端设计师领地

随着模式库的流行，Dave Rupert 认为我们需要为每位客户提供“微型 Bootstrap”。

响应式交付产品应该是风格类似 Twitter Bootstrap 的全功能系统，可根据客户的需求量身定制。

他切中了要害，特别是“为客户需求量身定制”这部分。这就是设计系统爆炸式增长的源头：所有这些模式库都包含了某种解决组织棘手的 UI 问题的方案。

回到 Bootstrap 上来，过去的问题是开发人员可以把 Bootstrap 的 CSS 和 JS 文件连接起来，但必须手动将 Bootstrap 的 HTML 转换为他们自己的环境。

在这个全新的世界中事物有另一套运行机制。我们现在拥有可直接消费的组件，这意味着组件的结构、样式和行为都可以打成一个简洁的包。这从很多层面上带来了令人激动的变革。

在 React 世界中有像 Material UI 和 React Bootstrap 这样的框架，可以将这些流行的前端 UI 库转换为可直接消费的 React 组件。这些预制解决方案自有其用武之地，但同时许多组织还在制作自己的自定义 UI 组件库以满足需求，诸如 Salesforce 的 React 闪电设计系统、IBM 的 React Carbon 设计系统、Shopify 的 Polaris 等等。

因此考虑到可直接消费的 UI 组件，我对 Dave 的观点修正如下：

前端设计交付产品应该是风格类似 React Bootstrap 的全功能系统，可根据客户的需求量身定制。

这是一个微妙但重要的区别。前端设计人员不仅可以创建组件的参考 HTML、CSS 和展示 JS，还可以创建可直接消费的 HTML、CSS 和展示 JS，然后让后端开发人员为其注入活力。但请注意，“根据客户需求量身定制”的原则没变。我不是说“只使用 React Bootstrap”，而说的是要创建一个 UI 组件库来满足你的特定需求。

在我看来，可直接消费的 UI 组件可以作为大分工之间的桥梁。它在前端的前台和前端的后台之间创建了良好的沟通渠道。

所以为了实现这一点，在本文开头列出的职责列表中需要添加以下内容：

• 创建一个展示 UI 组件的库。然后打包起来供其他开发人员使用。

• 为每个展示组件编写一个稳健且直观的组件 API 及 API 文档。以便使用组件的开发人员可以轻松将所需内容插入组件中。

• 确定组件库应该有多大的灵活性或刚性。与开发人员合作，确定每个组件应该是开放/可组合还是硬性/锁定的。

• 将展示组件作为产品来维护。这意味着我们必须处理版本控制、部署、管理、发布说明等维护软件产品的各种操作。

最重要的是，我们必须卷起袖子学习像 React 这样的 JS 框架。也不是要学习和 React 相关的所有内容，只学对前端设计工作有用的 React 知识即可。

可消费的 UI 组件长什么样？

这种组件长什么样呢？例如一个警报组件：

组件的基础内容（用 JSX 编写）如下所示：

<div  className={`c-alert ${variant}`}  role='alert'  {...other}>    <Icon      name={iconName}      className='c-alert__icon'    />  <div className='c-alert__body'>    <h2 className='c-alert__title'>{title}</h2>    <div className='c-alert__description'>      {children}    </div>  </div></div>

我们正在为由应用程序开发人员填写的动态数据（例如标题）创建插槽。

组件构建好后应该能让别人使用。一种方法是在应用程序中放一个“ui-components”文件夹，但更好的方法是将它作为自己的产品发布出去（看，我正在发布我自己的 UI 框架！）。这样一来其他开发人员就能用下面的命令获取你的组件库：

npm install our-react-design-system

组件库安装好后开发人员就可以插入这个警报组件：

import Alert from "our-react-design-system/components/Alert";<Alert   variant="success"  iconName="checkbox"  title="Profile updated!">  You have successfully updated your profile.</Alert>

这个副本来自哪里？是什么引发了警报？这就是后端开发人员操心的事情了。他们把这些展示组件包装在智能层中，这些智能层处理业务逻辑、数据操作等实现该警报组件所需的内容。

我喜欢可消费的 UI 组件

我同 React 打交道的这一年半时间里，我最喜欢的内容并不是 React 专属的，它就是可直接消费的组件这个概念。这也是为什么我对 Web 组件热情高涨的原因所在，因为它们是 Web 原生的，可以与不同的 JS 框架互操作。

可直接消费的 UI 组件的概念有很多优点：

• 它集中了前端代码库。允许前端专家在单一源头中管理标记、样式和展示 JS。这样就不会让前端代码散落得到处都是，并让前端设计人员更加慎重地设计前端代码架构。他们可以迭代并改进 UI 组件代码，并将这些更改传播到使用组件的所有场景中。

• 前端设计人员控制了前端代码。我参与过的很多项目中，很多非前端开发人员复制并粘贴了他们需要的标记，并省略了他们不理解的属性。果然，ARIA 属性似乎神秘地消失了，div 被直接推到了 ul 标签下，文档结构自然一团糟。以前这种情况下前端设计师无能为力，只能在深夜独自垂泪。但使用可直接消费的 UI 组件后，前端设计人员就能保持对 UI 代码的控制权，并为其他开发人员提供与之交互的 API，不用再暴露源标记、样式和展示 JS 了。

• 可以将最佳前端实践融入组件。令人激动的重大变革。由于 UI 组件现在是集中管理的，因此你可以将最佳前端实践融入组件中，而其他开发人员可以免费获得这些最佳实践。我之前写的文章介绍了自动生成 ID 以创建更易访问的表单控件的方法。应用程序开发人员不用再操心需要死记硬背的细节事项，可以腾出精力专注于其他更有价值的任务。

我的工作流程

我最近的演讲谈到了我的这种新工作方式的流程，要点包括：

• 在Storybook中做一个前端工作室环境，通过构建代表性的产品页面来构建 UI 组件。网上的大多数 Storybook 只有级别较低的组件，但我们使用 Storybook 来展示我们所有的产品页面。这些页面都是实际可用的，由团队审查，后端开发人员将页面连接到后端服务和应用程序的其他部分时可以用这些页面当参考。

• 在构建产品屏幕时，我会为每个组件创建一个 API。应该是<Button text =“Click Me”/>，<Button label =“Click Me”/>，还是<Button> Click Me </Button>呢？我最喜欢的工作就是创建一个直观、一致的组件 API 了。

• 我们与利益相关方一起审查我们的页面和组件。当大家都满意后，我们发布一个包含所有新组件、变体和修复的组件库新版本。

• 然后，应用程序开发人员将最新和最完整的更改下载到他们的应用程序中，以接收新功能和更新。

具体的工作流程涉及很多细节，需要单独撰文介绍了。

我在 React 世界中仍在设法解决的问题

作为前端设计师，我很高兴自己终于在 JS 的新世界中找到了立足之地。之前很多人都希望我能分享我的 React 旅途中的新动态，这篇文章就是答案。虽然 React 有很多令人喜爱的地方（特别是我在上面重点介绍的可消费组件），但有些情况下我还是会遇到问题，或者还在寻找解决办法：

• 我还是不喜欢编写 JSX。虽说现在我写得流畅多了，但还是觉得它很奇怪。具体细节就不谈了，以免引来一堆愤怒的评论。我只能说转到需要编写 HTML 或类似内容（例如 Vue）的项目时，感觉就像一股清新的空气扑面而来一样。

• React 和它的小伙伴们。推荐https://www.youtube.com/watch?v=ANtSWq-zI0s">Evan 的这个演讲]，解释了 React 库本身为什么有意做成轻量化的，所以做应用时还需要加上其他库。轻量化设计使 React 有了一个庞大的生态系统，带来了巨大的成功。但如前所述，这也意味着你要处理各个库之间的接口，还要跟上 React 与它的伙伴们的飞快步伐。我不是算命先生，但我有预感很多团队都将花好长时间才能解开之前的“新热点”纠缠成的一团乱麻。

• 社区中的强势意见。我正在与一位 React 信徒探讨我们的团队该怎样重构我们的 Accordion 组件，以便客户可以使用 Redux 来管理面板的开放/关闭状态。他的反应是：“噗嗤，现在没人再使用 Redux 了！”呃，可真的有人在用啊。React 社区有很多人大声呼吁，语不惊人死不休，让我更感到混乱不堪了。我合作的团队都说他们为了跟上潮流实在是费劲。

• React 信徒营造的准宗教氛围。只要我评论或批判 React 甚至它的相关事物，就会有人蹦出来让我闭嘴。我没把 React 当成救世主和上帝，所以很多人非常生气，任何质疑、批评都成了亵渎行为。当然 React 有很多优点，可它也就是个工具而已；的确这些工具是别人开发的，但我们也要知道这些技术和概念与它们的创造者和使用者是两码事，讨论前者并不需要小心翼翼。

• 搭建工具链和构建的过程让我头昏脑胀。有的人喜欢这些流程，但我不喜欢，最好让其他开发者帮我搞定。我用来展示的 React 设置很好用，但涉及到应用代码库时就让人头晕眼花了。

• 还得辨别什么是真正的趋势，什么又是自吹自擂。有条推文题目是“现代前端设计系统栈”，内容只是列出了几个 GitHub 项目而已，就这还系统栈呢。我就当本季流行时尚手册来看了。而真正的趋势会影响我的工作方式，我时常问自己“这件事和我的工作有没有关系？”Hook 就有关系，路由和状态管理有一点点联系，数据存储可能无关紧要。当然有的人需要关心这些事情，我希望与他们密切合作。

我想看到什么

• 我希望看到更多的前端设计师站出来，学习 React（和/或其他 JS 框架和/或 Web 组件）的前端部分。再说一遍，你不必学习 React 的所有相关内容，只需学习可以为这些环境提供出色的标记、样式和展示 JS 的部分。这会对你创建的产品带来直接而重要的贡献。

• 我希望看到后端开发人员认识到前端设计的重要性。并在代码库中为前端人员腾出空间。当然，现在什么事情都在 JavaScript 的范畴之内，但划出界限还是很重要的，所以要尽量为其他领域的技能留出展现价值的空间。

• 求求大家了，请意识到专家的价值所在。组织别再假模假样地雇用一些“全栈开发人员”了，聘请一些专家吧。因为要做的工作太多了。前端的前后台都需要专业人士处理，专家才能精于此道，而全才只能给出及格分而已。

• 我希望看到组织/行业层面更加细分需求。“我们正在招聘一名 React 开发人员”到底是什么意思？“React 开发者”和“前端开发者”都是很宽泛的说法，所以要澄清一下。你在寻找的是专注于标记和样式的员工？还是要创作中间件和业务逻辑？抑或是负责管理数据和数据库？管理构建流程？别说什么都要干，参见上一条。

• 因为现在“一切都是 JavaScript 包揽”、“一切都是组件”，所以在这种大环境下做好区分需要缜密的思考。这还是细分的话题。我非常喜欢将 UI 组件库作为一个单独的产品进行管理的想法，因为这样以来前端的前后台之间就有了明确的分界线。无论如何你的项目都要区分清楚 UI 侧的代码与应用侧的代码。另外非常重要的是在代码库中为不同专业的人留好各自的空间。

• 别再扯什么 React 爱用不用之类的废话了。这样讲话有意义吗。是团队选择技术方案，要创造能让擅长不同技术的人们通力协作的环境，而不是把人随便踢出去。

• 学习这些库是可以的，但没想当什么全栈开发人员。有的前端人员也会干后端工作，反之亦然；很多人想做全栈，也很棒！但做专家也很有意义，要做的事情太多了，谁的才能都有施展的空间。

这是一次有趣的旅程，我期待能继续学习和提升下去。感谢阅读。

英文原文：http://bradfrost.com/blog/post/frontend-design-react-and-a-bridge-over-the-great-divide/