组件级 CMS

当组件位于数据查询填充它并位于附近的环境中时，视觉组件和存放该确切内容的数据库之间存在一条相当直接的路线。 这为沿着这条路线的站点编辑体验打开了大门。 我们开始看到直接利用这一点的 CMS。

例如，如果我在构建我的网站时使用 <Query /> 组件编写 GraphQL 查询以获取所需的数据，那么更改该数据并将其放回 <Mutation /> 组件中是有道理的。

看看 TinaCMS，它正在吸引很多关注。

我刚看到了 BodilessJS，它也是沿着这条路线发展。 他们正在尝试创造一个新的术语——其中无头站点的内容来自无头 CMS（通过 API，即内容位于其他地方，而不是与站点本身一起）而无体站点的内容与站点位于同一个仓库中。 嗯，我对这个词并不十分热衷，但这种类型的站点可能确实需要某种分类。

Stackbit 正在开发一款名为“Stackbit Live”的产品，它也是沿着这条路线发展。 这是一个来自他们互动演示的截图，让你了解一下

所有这些似乎都集中在 React 上，并带有“可能以后会使用其他东西”的氛围。

我去年与 Webflow 制作的（赞助的）视频 具有非常类似的 CMS 体验。 由于视觉组件和它背后的数据之间存在直接联系，他们的 CMS 能够做到的事情令人难以置信。

对这种站点体验的需求一直存在。 我记得一些服务是这样的：“只需在你的元素上放置我们的特殊类和 FTP 凭据”，这样就可以让你登录他们的网站并使用 UI 编辑元素上的内容。 它会将更改直接上传回服务器上的静态文件中。 我不确定这些服务是否还存在，因为它们一度过时了。

以稍微更现代的方式，Lea Verou 的 Mavo 也是这样。 你唯一可以编辑内容的地方是前端。

我认为，对于某些站点来说，这种类型的编辑体验一直都是非常可取的。