Shopify 正在走向平庸

Shopify Editions | Winter '24 观后感[https://www.shopify.com/editions/winter2024]：
就是 Shopify 在走向平庸（尽管 Editions 上展示的更新对卖家来说，操作上越来越傻瓜）

图片来源：Shopify Editions | Winter '24

但作为开发者的角度来看，感觉最明显缺失的是对 Liquid 和更深层次主题架构的任何重大改进；

（当然，Theme Blocks 的确让更多东西更容易被搭建）

这就是我们觉得最可惜的地方，Editions 仍然缺少对 Liquid 和底层基础设施的改进。

Liquid 是一种模板语言，意味着它的工作是将数据结构化，因此有循环和条件，这些都是需要渲染
而 Shopify 的主题架构缺少的是一种准备数据的方法，templates 中的数据来自 Liquid Drops，文档将它们称为 objects 。

在大多数情况下，在模板、部分或片段中访问的是全局对象，所以为了为更好的 view 而需要准备更具体的数据，开发者就在收集功能非常糟糕的情况下进行转换，并且在数组上这样操作，就好像带着手套打字一样。。。

（常见模式，顶部的一大块Liquid，由多个循环和将东西插入数组的条件组成）

图片来源：Shopify开发实例

最反直觉的就是，作为 Rails 开发人员的第一反应就是——我的 controller 去哪里了？

controller 不工作其实是因为没有适当的方法来准备数据，而且 Metabjects 是隐藏在显眼位置的数据库表。这意味着开发者变为一个查询关联的 feature 而不是开发。

All this 在 Liquid 中都非常笨拙。

当然，这可以说是 Shopify 对向后兼容性的看重

——所以就如同我开头的吐槽一样，Shopify 在走向平庸了，否则不会对于为开发人员提供更高级的工具的步伐上那么缓慢：

Liquid 其实是可以改进以获得更好的数据收集支持的

方法一是可以引入一个新的标签，比如包含所有数据准备代码的样式表或模式标签，需要一种方法将此代码与实际视图代码分开，以使缓存变得容易。

（个人觉得 Shopify 的某个地方一定藏着某种俄罗斯套娃缓存）

另一种方法是采用 Shopify 一直在为后端扩展部署的 Functions/wsom 基础架构，涉及定义 GraphQL 输入和输出以及业务逻辑。

从概念上讲，这种方法表面上更复杂，但更容易理解，毕竟还允许开发者可以使用 Functions 一样使用任何编译为wass的语言。

Shopify 也好，Shopify 卖家也好，以及开发者也好，在越加复杂系统需求的当下，需要的不仅仅是构建Theme Blocks 的方法，更需要一种功能更丰富的方式继续构建 Shopify 的生态世界。

（来源：JaronTam）

以上内容属作者个人观点，不代表雨果跨境立场！本文经原作者授权转载，转载需经原作者授权同意。​