CMS 的未来形态

三位球员

CMS 要求

当前的解决方案

CMS 的未来形态

在本文中，我阐述了我对内容管理系统未来的看法。我认为，CMS 尚未充分利用我们在 Web 开发领域见证的代码与设计融合的优势。
恰恰相反，开发者们所钟爱的前后端分离模式，却导致内容编辑者的用户体验恶化。
我认为现在是时候改变这种现状了。

三位球员

CMS 的采用和使用涉及三类人员：内容编辑、设计师和开发人员。这些人代表了 CMS 的核心部分：内容、内容呈现以及交付内容的基础设施。
如今，一个优秀的 CMS 需要满足所有这些人员的需求。
让我们来看看这些需求是什么。

CMS 要求

内容编辑的梦想

对于内容编辑者来说，CMS 应该易于使用、灵活（内容创建的自由），但也应该提供一种“引导式”编辑体验，以避免重复和错误。

开发者的梦想

开发人员喜欢后端API和现代堆栈前端带来的关注点分离。网站可以自由托管在任何地方也是一大优势。

设计师的梦想

设计师寻求一种方法来强制实现一致的用户体验/用户界面/品牌标识。这导致他们希望与开发人员使用共同的语言，并制定一套规则，以防止内容编辑者破坏设计。

要求摘要

当前的解决方案

内容编辑器工具：所见即所得

传统 CMS 为内容编辑者提供了一项很棒的功能：所见即所得 (WYSIWYG) 编辑。实时查看内容在前端的呈现效果是一项很棒的功能。而像 Wordpress 这样的传统 CMS 通常会面临权限过大的缺点。在空白的所见即所得页面上，编辑者可以随心所欲地编辑，这可能会损害品牌形象。一旦你尝试强加规则（例如在 Wordpress 中使用 ACF 自定义帖子类型），你就会突然失去所见即所得的能力，回到灰色表单。

前端开发人员的工具：无头 CMS

无头 CMS 负责 CMS 的“后端”，提供数据库、API 以及通常用于编辑内容的 Web 界面。API 实现了后端和前端之间的关注点分离，这一点深受开发人员的喜爱，因为 REST（或 GraphQL）API 与前端无关。

使用 JS 前端

使用无头 CMS，前端开发人员拥有一个可立即使用的后端，因此他们可以自由地使用自己喜欢的工具创建前端网站，特别是使用 React、Vue 或 Angular 等 Javascript 框架。

两种技术使单页应用程序具有出色的性能和 SEO 友好性：服务器端渲染（SSR）和静态站点生成（SSG）。

静态网站

特别是，我认为静态站点生成非常有前景。

静态网站是：

• 非常快（运行时无需数据库查询、智能内容预加载、通过 CDN 分发）
• 易于托管（在Netlify或Zeit Now等云平台上，您通常可以保留免费套餐）
• 稳健（它们不需要复杂的基础设施，并且不会出现问题）
• 安全（它们提供最小的攻击面）

所见即所得的头脑已经消失

这种内容与呈现之间的关注点分离，对开发者来说非常有利，但却扼杀了内容编辑者所钟爱的所见即所得的编辑界面。
事实上，无头CMS提供的内容创建界面对前端如何格式化内容一无所知。这会导致编辑者的用户体验下降
。 此外，还存在其他问题，例如文本中存在从一个资源到另一个资源的链接，而前端内部链接应该被替换为框架特定的标签，以便使用基于推送历史记录的客户端路由器。

设计师的工具：设计系统

设计系统（请设计师原谅我简化的定义）是一组视觉组件、规则和资源，有助于保持一致的品牌标识和用户体验。

因此，要在 CMS 中部署设计系统，我们需要：

• 定义一组与开发人员共享的可视化组件
• 强制编辑者正确使用这些组件（块）

JSX 是一种通用语言吗？

我认为，目前开发者和设计师之间定义可视化组件的通用语言的最佳选择是 JSX。它与 HTML 非常相似，但表达能力更强。我可能因为喜欢 React 而偏爱 JSX，但你也可以在 Vue 中使用 JSX。也许未来的最佳选择是标准化的 Web 组件，但目前我更倾向于 JSX。JSX的 props也是限制编辑器界面和设置组件可操作规则的好方法。

混合CMS：错误的解决方案

我们发现，使用无头 CMS 会失去传统 CMS 的一大优势，即使用所见即所得编辑器编辑内容的能力。
混合 CMS 试图通过提出一种也公开 API 的传统 CMS 来解决这个问题，就像带有 REST API 的 Wordpress 一样。这样，提供的前端是可选的。
实际情况是，根据您的使用方式，您要么拥有所见即所得编辑，要么拥有 API，但不能同时拥有两者。
实际上，我认为现有的混合 CMS 更注重编辑器，因为它们通常处于“无代码”状态，仅为开发人员提供 API 糖丸，如果不失去混合方法的优势，这些编辑器就不会在网站上使用。

目前的解决方案总结：

CMS 的未来形态

我们如何才能同时拥有所见即所得的编辑体验和使用React、Next.js、Gatsby等 JS 框架创建的自定义前端，同时又能保持前端的自主托管能力？如何在编辑内容界面中强制执行设计系统？

共享架构

我认为关键是编辑界面和前端之间的共享模式。

该模式是一组由设计师和开发人员创建的Web 组件和规则。我认为这些组件将在JSX中定义，以便规则可以利用组件的“props”。CMS 将提供一种 WYSIWYG 方式编辑部分内容，并使用“画布外”编辑某些 props（如图像 ALT 文本或背景颜色）。内容编辑器做出的任何选择都应简单且有指导，并提供有限（但完整）的可用选项。
通过这种方式，API 只会返回实体的 JSON 内容。前端使用 CMS 提供的库和共享的规则/组件集，将简单地呈现与内容编辑器在编辑区域中看到的完全相同的界面。

第一块砖

• 好消息：我们正在尝试创建这种 CMS：它的名字将是React Bricks :)
• 坏消息：这是一项艰巨的任务。
• 但是：我们坚信这一愿景，我们对这个项目感到兴奋，而且我们几乎已经拥有了一个原型。

同时，您可以看到几周前创建的编辑器的第一个原型：

艰巨的任务是什么？

第一个是组件和模式定义：我们希望设计人员或开发人员角色的用户能够从管理界面编辑它们。但这并非易事：我们需要重建类似Code Sandbox 的东西，以便用户在其块组件中使用外部依赖项。
第一个原型将是一个基于 create-react-app 的项目，用于克隆，用于创建内容编辑仪表板。在这个项目中，您将定义和测试组件和模式。

第二个是在内容编辑界面和前端之间共享架构、块和样式的方法。我能想到三种方法：

• 将代码从管理项目复制并粘贴到前端
• 拥有一个npm（或我们的注册表）存储库
• 通过 CMS 数据库共享

我们将从第一个解决方案开始。我们的目标是实现第三个解决方案。

更新于 2020 年 2 月 12 日，
我以一种全新的方式解决了这个问题：管理员和前端就是同一个 Next.js 或 Gatsby 项目！（/admin）🎉🎉

第三个难题是解耦管理界面和编辑内容之间的 CSS 样式。首先，我们将在 React Bricks 和内容组件中使用Tailwind CSS。我们将在后续版本中克服这一限制。

更新于 2020 年 2 月 5 日，
我使用 React Portal 解决了 CSS 解耦问题！🎉

当我们努力完成原型和完整的演示时，请让我知道您对我的想法的看法。

感谢您的时间...请继续关注 React Bricks 的更新！