Liquid: Geleceğe Dönüş

Shopify, Tema Yapısını Okunabilir Koda Geri Taşıyor—ve Bunun Geliştiriciler, Satıcılar ve Ajanlar İçin Ne Anlama Geldiği

Tam 12 yıl önce bugün, ilk Shopify mağazamı kurmaya başladım.

Tam anlamıyla bir geliştirici değildim. HTML, CSS ve tehlikeli olacak kadar jQuery bilen, teknolojiye meraklı bir tasarımcıydım. Tek bildiğim, kurduğum markaya tamamen özel bir mağaza vitrini istediğimdi—ama bunun için tüm bir e-ticaret altyapısını yönetmek istemiyordum.

Sonra Shopify'ı buldum.

Timber'ı indirdim, koleksiyon şablonunu açtım ve her şey yerine oturdu:

1{% for product in collection.products %}
2  {% include 'product-grid-item' %}
3{% endfor %}

Şablonun tamamı 100 satır koddan oluşuyordu. Sadece kodu okuyarak nasıl çalıştığını anlayabiliyordum. Mark Dunkley'in kopya kağıdı dışında neredeyse hiç dokümantasyona ihtiyacım olmadı.

Tema geliştiricileri için bu, okunabilirliğin altın çağıydı. Satıcılar içinse, küresel Tema Ayarları açıkça yeterli değildi.

Yaptığımız ödünleşim

Tema ayarları bizi ancak bir yere kadar götürdü. 2016'da Shopify, Bölümler'i (Sections) tanıttı ve aynı anda üç şey değişti.

1. Satıcılar, merchandiser haline geldi. Kod yazamayan kişiler sayfaları şekillendirebilir ve çok daha zengin bir ürün hikayesi anlatabilirdi.
2. Geliştiriciler, bileşen tasarımcıları oldu. Bölümler modüler, esnek ve her sırada çalışabilir olmalıydı.
3. Ve temalar, ürün haline geldi. Geliştiriciler, oluşturdukları arayüzü düşünmek ve kullanım kolaylığı ile esneklik arasında bilinçli ödünleşimler yapmak zorundaydı.

Bu güçler, 2016'da Dawn ile, geçen yıl Horizon ile ve temalarda temel birleştirilebilir birim olarak "blokların" tanıtılmasıyla daha da hızlandı.

Shopify'ın, bölümleri ve blokları her şablonda temsil edebilmesi için bir serileştirme formatına ihtiyacı vardı. Şablonlar JSON'a taşındı.

Bu ödünleşim, satıcılara çok daha fazla kontrol sağladı, ancak bir geliştirici deneyimi maliyetiyle geldi: artık tek bir dosyayı okuyarak bir sayfayı anlayamıyordunuz. Sayfanın nasıl çalıştığını yeniden yapılandırmak için JSON, Liquid, şemalar, ayarlar, bölümler ve bloklar arasında çapraz referans yapmanız gerekiyordu.

Şablonlar JSON haline geldiği anda, harika bir geliştirici yüzeyi olmaktan çıktılar. Otomatik kaydedilen bir çıktı haline geldiler—geliştiricileri elle düzenlememeleri konusunda uyardığımız bir şey.

Bu, "zorunlu yazılım" çağı için mantıklı bir ödünleşimdi; satıcıların bir mağazayı butonlar, düğmeler ve ayarlarla şekillendirerek tam olarak neyin değişmesi gerektiğini belirttiği bir çağ.

Yapay zeka denklemi değiştiriyor.

Harika bir geliştirici deneyimi, harika bir ajan deneyimidir

Sidekick'e temaları düzenleme yeteneği verdiğimizde, Çevrimiçi Mağaza Düzenleyicisi "bildirimsel yazılım" çağına girdi. Basit bir örnek: bir renk seçici açıp \[#0000FF](https://x.com/search?q=%230000FF&src=hashtag_click)\ seçmek yerine, bir satıcı sadece "Bunu mavi yap" diyebiliyordu.

Satıcılar bu yıl zaten 25 milyon Sidekick tema düzenlemesi yaptı ve her 5 satıcıdan 1'i temasını düzenlemek için yapay zeka kullanıyor.

Aynı zamanda, geliştiriciler kod yazmak için giderek daha fazla ajan kullanıyor. Bu, Shopify'ın artık birbiriyle bağlantılı iki görevi olduğu anlamına geliyor:

1. Ajanlara daha iyi rehberlik sağlamak.
2. Onlara daha iyi geri bildirim vermek.

Rehberlik için, geliştirilmiş Liquid becerileri yayınlıyoruz. Temalar ayrıca bir \.agents\ dizini aracılığıyla ajan talimatları taşıyabilir ve kodlama ajanlarının kodun nasıl yazılmasını istediğinizi ve tasarımlarınızı markaya uygun tutmayı anlamalarına yardımcı olmak için \AGENTS.md\ ve \DESIGN.md\ gibi dosyalar içerebilir.

Geri bildirim için, \{% doc %}\ etiketini, snippet'ler ve bloklar için yazılı sözleşmelere dönüştürdük. Parametreler belgelenebilir, tiplendirilebilir, Tema Kontrolü (Theme Check) tarafından doğrulanabilir ve nasıl kullanılacağına dair örneklerle eşleştirilebilir.

1{% doc %}
2  @param {string} [variant]
3  @param {string} [tag]
4
5  @example
6  {% block 'text', tag: 'h1' %}
7    Featured Collection
8  {% endblock %}
9{% enddoc %}

Kodu elle yazarken bu size anlık geri bildirim, akıllı tamamlama (intellisense) ve hatalar verir; ayrıca ajanlara geçerli parametreleri keşfetme, iyi çıktının neye benzediğini öğrenme ve var olmayan bir API'yi halüsinasyon gördüklerinde uygulanabilir geri bildirim alma imkanı sağlar.

Ayrıca sözleşmeler, yapı, doğrulama, karmaşıklık, iç içe geçme ve dosya boyutu sınırlarını kapsayan 20 yeni Tema Kontrolü kuralı ekledik.

Ajan çağında benim gibi geliştiriciler için harika olan şey, her zaman istediğimiz şeyleri ödüllendirmesidir: okunabilir kod, açık sözleşmeler ve hızlı geri bildirim.

Bu yüzden daha büyük bir soru sorduk: bu nitelikleri temel prensipler olarak ele alsa, ideal tema mimarisi neye benzerdi?

Tüm fikirlerimizi bir araya getiren yeni bir Shopify temel teması oluşturuyorduk.

(Belirtmeliyim ki… bu, kodlama ajanlarını optimize etmek için yeni bir mimari, ancak zorunlu bir yeniden yazım değil. Mevcut temalar sonsuza kadar çalışmaya devam edecek; Liquid her zaman oldu ve her zaman sonsuza kadar bir API olarak kalacak.)

Sayfa yapısı yeniden okunabilir kod haline geliyor

Yeni temada fark edeceğiniz ilk şey, \templates\ dizinini açtığınızda; şablonların yeniden Liquid dosyaları olması.

Koleksiyon şablonu kabaca Timber ile aynı uzunlukta ve genel tema, Horizon'dan %93 daha az kod satırına sahip. Bu, Horizon gibi pilleri dahil bir tema olmak için tasarlanmadı; Shopify'daki tüm e-ticaret temel öğeleriyle oluşturmayı gerçekten kolaylaştırmak ve mümkün olan en iyi performansı elde etmek için bir temel oluşturmak, ancak her satıcının mağazasını benzersiz kılan her şeyi sizin oluşturmanıza izin vermek için var.

Sayfa yapısını neden Liquid'e geri taşıyoruz?

Serileştirilmiş yapılandırmayla ilgili daha derin sorun, JSON'un doğası gereği kötü olması değil. Yapılandırmanın kısıtlı bir kelime dağarcığına sahip olmasıdır. Bir tema geliştiricisi, bir satıcının isteyebileceği kompozisyonları tahmin etmek zorundadır.

Bir buton içeren bir bölüm hayal edin. Bir satıcı, bir ajandan yanına ikinci bir buton eklemesini ister.

Ayarlar odaklı bir mimaride, temanın her iki butonu da tutabilecek bir grup bloğunu zaten açığa çıkarması veya geliştiricinin ikinci bir buton ayarını tahmin etmiş olması gerekir.

HTML'de, başka bir buton eklersiniz ve çifti bir \div\ içine sararsınız.

Her önde gelen model zaten HTML'i anlıyor. HTML anlatımsal, yerel ve token açısından verimlidir. Ve Shopify, bu anlatımsallığı e-ticaretle birleştirmek için gereken dile 20 yılı aşkın süredir sahiptir: Liquid.

Bloklar ve HTML, birlikte

Yeni mimari, doğrudan Liquid şablonlarının içinde kullanılabilen birleştirilebilir bir \{% block %}\ etiketi sunar.

1<div class="mb-8">
2  {% block 'text',
3    tag: 'h1',
4    block.settings.variant: 'type-heading-xl',
5    class: 'mb-2'
6  %}
7    {{ collection.title | escape }}
8  {% endblock %}
9</div>

Bloklar, adlandırılmış parametreler kabul eder. İç içe içerik içerebilirler. Parametreleri \{% doc %}\ aracılığıyla tiplendirilebilir. Satıcıların etkileşime girebileceği sınırları tanımlarken, sıradan HTML her şeyi halleder.

React gibi bir bileşen sistemi kullandıysanız, model tanıdık gelecektir: parametreler prop'lar gibi, iç içe içerik ise children gibi davranır. Ancak Liquid olarak kalır—tek bir dosyada yukarıdan aşağıya okumak için yeterince basit.

Bu, her bir işaretleme parçasının başka bir bölüm, blok veya ayar haline gelmesini gerektirmeden kompozisyonu açık hale getirir.

Kısmi güncellemelerle ince taneli reaktivite

Tema geliştiricileri, Bölüm Oluşturma API'sini (Section Rendering API) orijinal olarak tasarlandığının çok ötesine taşıdı çünkü sunucu odaklı reaktivite için mevcut en iyi araçtı.

Daha hassas bir şey istedik.

Bildirimsel kısmi güncellemeler üzerine ortaya çıkan çalışmalardan ilham alarak, Liquid'e partials adı verilen basit bir ilkel getiriyoruz.

Yeniden oluşturulabilir bir bölgeyi sarın:

1{% partial 'cart-count' %}
2  <span>
3    {{ 'cart.count' | t: count: cart.item_count }}
4  </span>
5{% endpartial %}

Ardından taze HTML alın ve gereken yere uygulayın:

1const html = await partials.fetch('cart-items', 'cart-count');
2partials.apply(html);

Bu kadar. Tüm bir bölümü oluşturmadan veya sanal bir DOM tanıtmadan ince taneli, sunucuda oluşturulmuş güncellemeler.

Sepete ekleme, birkaç satırda ilgili sepet bölgelerini güncelleyebilir. Bu tek ilkel, Horizon'dan binlerce satır reaktivite kodunu kaldırmamızı sağlayacak.

Standart Olaylar ve Eylemler

Ayrıca, yaygın mağaza ön yüzü etkileşimlerini daha basit ve daha birlikte çalışabilir hale getiriyoruz.

Standart Eylemler (Standard Actions), bir sepeti güncelleme gibi işlemler için paylaşılan bir sözleşme sağlar. Standart Olaylar (Standard Events), temaların ve uygulamaların aynı kararlı kelime dağarcığı aracılığıyla tepki vermesini sağlar.

1const { cart } = await Shopify.actions.updateCart({
2  lines: [{
3    merchandiseId: variant.id,
4    quantity: 1,
5  }],
6});

Bu, geliştiricilerin yazması, uygulamaların entegre olması ve ajanların anlaması için daha kolaydır. Standart Eylemler bugün Shopify mağazalarında çalışır ve WebMCP desteği, tarayıcı ajanlarına, mağaza ön yüzü bu etkileşimlere yanıt verirken, ürünlere göz atmak ve eklemek için anlamsal bir yol sağlar.

Amaç, mağaza ön yüzüne bir "AI modu" eklemek değil. Mağaza ön yüzünün yeteneklerini her katılımcı için (temalar, uygulamalar, geliştiriciler ve ajanlar) net ve birleştirilebilir kılmaktır.

Liquid'i Geliştirmeyi Daha Güvenli Hale Getirmek

Ayrıca Liquid'e eklemek istediğimiz bazı bariz dil yetenekleri vardı: boolean ifadeleri, öncelikli infix operatörleri ve değişmez diziler ve nesneler.

Engel, istek eksikliği değildi. Liquid'in tarihsel ayrıştırıcısı, biçimsel olarak geçerli olmayan belirsiz sözdizimini kabul ediyordu. Bu nedenle yeni sözdizimi eklemek, mevcut temaların nasıl davrandığını değiştirebilirdi.

Ekip, temaları güvenli bir şekilde katı bir ayrıştırıcıya taşımak için büyük bir geçiş üstlendi. Bu çalışma, bize zaten ona bağlı olan mağaza ön yüzlerini bozmadan Liquid'i geliştirme alanı sağlıyor.

Daha basit, daha tanıdık ifadelerin önünü açıyor:

1{{ 1 + 1 }}
2{{ false && false || true }}
3{% assign products = ["shirt", "hat", "shoes"] %}

Ayrıca hataları—geliştiriciler ve ajanlar için—daha öngörülebilir hale getiriyor.

Bir şey daha: Tailwind

Yakında, Liquid temalarına Tailwind desteği getiriyoruz.

Ajanlar bu konuda harika. Geliştiriciler zaten anlıyor. Ve bize, satıcıları karmaşık bir derleme sistemini miras almaya zorlamadan, tasarım token'ları etrafında inşa edilmiş paylaşılmış bir stil dili sağlıyor.

Bu paylaşılan kelime dağarcığı önemlidir. Ajanlar yapıyı, sözleşmeleri ve stil niyetini ne kadar iyi anlarsa, geliştiriciler bir markayı gerçekten farklılaştıran mağaza ön yüzü bölümlerine o kadar fazla odaklanabilir.

Geleceğe dönüş

On iki yıl önce, Shopify benim için bir temayı açıp, kodu okuyup mağazayı anlayabildiğim için yerine oturdu.

Zamanla, temaları satıcılar için çok daha esnek hale getirdik, ancak kodun içini görmek zorlaştı.

Ajanlar bize bu iki şeyi yeniden birleştirme şansı veriyor: satıcıların ihtiyaç duyduğu esneklik ve geliştiricilerin hak ettiği okunabilirlik.

Bu yeni mimarinin ardındaki yön budur:

• Okunabilir sayfa yapısı olarak Liquid şablonları.
• Sıradan HTML'in yanında birleştirilebilir, tiplendirilmiş bloklar.
• Ajan becerileri ve depo düzeyinde rehberlik.
• \{% doc %}\ ve Tema Kontrolü aracılığıyla daha zengin geri bildirim.
• Partials (kısmi güncellemeler) aracılığıyla ince taneli reaktivite.
• Standart Olaylar ve Eylemler aracılığıyla paylaşılan mağaza ön yüzü sözleşmeleri.
• Liquid'in güvenli bir şekilde gelişmesini sağlayan katı bir ayrıştırıcı.
• Ortak bir stil dili olarak Tailwind.

Geliştirici önizlemesi ve dokümantasyon artık mevcut:

https://shopify.dev/docs/storefronts/themes/getting-started/developer-preview

Bir şans verin ve geri bildiriminizi gönderin. Ne yapacağınızı görmek için sabırsızlanıyorum!