免費參與·100+跨境活動 
免費下載·4000+跨境資料 
免費學習·2000+直播課程 
免費加入·15萬+賣家交流群 
2024-02-04 14:00
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）
以上內容屬作者個人觀點，不代表雨果跨境立場！本文經原作者授權轉載，轉載需經原作者授權同意。?
收錄于以下專欄
