DE{CODE}: Gutenberg ve Başsız WordPress

WordPress blokları olarak da bilinen Gutenberg, içerik üreticilerine içeriği geleneksel bir WordPress sitesinde düzenlemeleri için güçlü ve yeni yollar sunar. Ancak kafasız WordPress geliştiricileri, pazarlama ekiplerini aynı yeteneklerle nasıl güçlendirebilir? Bu DE{CODE} oturumunda, GraphQL for WordPress'in (WPGraphQL) kurucusu Jason Bahl, WordPress blok düzenleyicisini başsız bir sitede kullanmaya yönelik yeni yetenekleri ve en iyi uygulamaları paylaşıyor.

Oturum Slaytları

Tam Metin Transkript

JASON BAHL : Merhaba. Gutenberg ve Headless WordPress hakkındaki konuşmama hoş geldiniz. Benim adım Jason Bahl. Ben WPGraphQL'nin yaratıcısı ve geliştiricisiyim. WP Engine'de baş yazılım mühendisiyim. Beni Twitter'da @jasonbahl veya ayrıca Twitter'da @wpgraphql bulabilirsiniz.

Bu yüzden bugün sizinle Gutenberg'in ne olduğundan, başsız WordPress'in ne olduğundan, ne zaman ve neden Başsız WordPress'i kullanmak isteyebileceğinizden, Gutenberg'i özellikle Başsız WordPress ile nasıl kullanabileceğinizden ve ne zaman ve neden Başsız WordPress ve Gutenberg'den bahsetmek istiyorum. birlikte projeleriniz için anlamlı olabilir.

Yani WordPress tarihsel olarak biraz buna benzeyen bir editöre sahipti. İçeriğimizi düzenleyebileceğimiz bir TinyMCE metin alanımız oldu. Medya ekleyebilir ve ardından içeriğimizi yayınlayabiliriz ve ardından 2018'de, bu boş tuvale içerik eklememize ve içeriğimizle blok düzeyinde etkileşime girmemize izin veren bu blok tabanlı düzenleyici Gutenberg geldi.

Yani her paragrafın ayarları vardır. Her görüntünün ayarları vardır. Her galeri, başlık - içerik için aklınıza gelebilecek her şey, blok olarak adlandırılan şeydir. Ve şimdi içeriğimizi nasıl kontrol edeceğimiz konusunda gerçekten ayrıntılı olabilir ve onu sürükleyip bırakabilir ve içeriğimizi oluşturabiliriz. Bu, şu anda WordPress'teki bu çok zengin düzenleme deneyimi ve bu yüzden Gutenberg'in ne olduğuna dair bir başlangıç.

Peki şimdi Başsız WordPress nedir? Headless'ı anlamak için geleneksel WordPress'e bakalım. Yani geleneksel WordPress, yönetici kullanıcı arabirimi olan WordPress'te oturum açarız ve içeriğimizi yayınlarız ve ardından kullanıcılar sitemizi ziyaret eder ve WordPress'in yerleşik dili olan PHP sayfayı oluşturur. Böylece CSS, HTML ve JavaScript'i yükler ve sayfayı kullanıcıya teslim eder. Yani bu bir tür geleneksel WordPress.

Headless WordPress ile WordPress'i CMS olarak kullanmaya devam edersiniz. Yine de WordPress'te içerik yayınlar, içeriği düzenler ve içeriği yönetirsiniz, ancak tarayıcıya HTML'de bir sayfa göndermek yerine, WordPress verileri tipik olarak JSON biçiminde sunar ve ardından istemci uygulamaları bu verileri kullanabilir, böylece yerel iOS veya Android uygulamalarına sahip olabiliriz. hatta sanal gerçeklik uygulamaları.

Meslektaşım Anthony, sanal gerçeklik uygulamalarını güçlendirmek için WordPress'i nasıl kullandığına dair bir içerik paylaştı. Ya da basılı gazetelerimiz için giriş noktası olarak WordPress kullandığımız bir gazetede çalıştım. Basılı bir gazetenin basılı bir kopyasını okuyorsanız, WordPress'te üretilen içeriği okuyorsunuz demektir.

Ve tabii ki, bu verileri web'de işlemek için de kullanabiliriz, ancak PHP şablonuna kilitlenmek yerine, istediğimiz ön uç teknolojisini seçme esnekliğine sahibiz. Böylece Headless, arka ucu, içerik yönetimini ve WordPress'te yönetilen verileri nasıl sunduğumuzu birbirinden ayırır.

Bu verileri kullanmanın iki yaygın yolu var. WordPress'in yerleşik bir API'si olan WP REST API'sinden JSON formatında veri alabiliyoruz ve WPGraphQL adında başka bir API var. Bu, WordPress ve JSON'dan veri yükleyebileceğiniz ve alabileceğiniz açık kaynaklı bir eklentidir. Ve bugün WPGraphQL hakkında konuşacağız.

Artık WordPress'in ne olduğunu bildiğimize göre, neden gidip Headless WordPress projeleri oluşturabilirsiniz? Bahsettiğim gibi, ön uç teknolojinizi seçerken çok fazla esnekliğiniz var. Ve bazı insanlar için ön uç projelerini nasıl inşa edeceklerini seçebilmek çok önemli bir şey. Next ve Gatsby ve Svelte gibi gerçekten geliştirilmiş temel web hayati özelliklerini hedefleyen bazı çerçeveler var. Böylece, WordPress ile Headless'a geçebilir ve temel web hayati değerlerini iyileştirebilirsiniz.

Kodunuzdaki kod bölme gibi şeylerden yararlanabilirsiniz. Böylece ön uç uygulamanız için bileşenler oluşturabilirsiniz. Belirli bir sayfa için hangi bileşenin oluşturulduğuna bağlı olarak müşteriye daha az veya daha az varlık gönderecek ve sayfalarınızı hızlandıracaktır. Headless ayrıca geliştiricilere ön uç kullanıcı deneyimi üzerinde daha hassas kontrol sağlar, böylece WordPress yöneticisine yüklenen eklentilerin ön uç üzerinde daha az etkisi olur.

Bu nedenle, yönetici kullanıcılar yalnızca eklentileri yükleyip bir Headless sitesinin ön ucuna rastgele komut dosyaları veya rastgele biçimlendirme ekleyemezler. Daha çok bir geliştirici ön uçtaki kısıtlamaları tanımlar ve WordPress gönderilen verileri alır ve ardından girmek istediğim şeylerden biri geliştirici deneyimidir.

Headless WordPress ile, istediğiniz teknoloji yığınını kullanma esnekliğine sahip olduğunuz için, bazı durumlarda daha iyi geliştirici deneyimi avantajı vardır. Ve ele alacağım bu durumlardan biri bileşen tabanlı geliştirme olarak adlandırılıyor ve birazdan bunun hakkında çok konuşacağız.

İşte bunun bazı nedenleri. Peki Headless WordPress'i kullanmak istediğinizde hangi durumlarda olabilirsiniz? Yerel mobil gibi web dışı uygulamalar oluşturmanız gerekiyorsa, muhtemelen Headless'a gitmek istersiniz. Yine, temel web hayati değerleriniz WordPress sitenizde, mevcut WordPress sitenizde zayıfsa veya iyiyse, ancak bunları iyi durumda tutmak çok maliyetli hale geliyorsa, Headless'ı düşünebilirsiniz.

Kuruluşunuzda WordPress'ten veri alması gereken birden fazla uygulamanız varsa, Headless'a da geçmeniz gerekebilir. Kuruluşunuz için zaten bir bileşen kitaplığına veya bileşen tabanlı tasarım sistemine yatırım yaptıysanız ve WordPress'ten verilere ihtiyacınız varsa, Headless'a geçmek için yatırım yapmak isteyebilirsiniz. Bir ekip JavaScript'i tercih ediyorsa ve PHP'de bir şeyler oluşturmaktan hoşlanmıyorsa, bu da Headless'ı düşünmek için bir nedendir.

Yine de Headless'a gitmek istemeyebileceğiniz bazı nedenler var - şu anda biraz fazladan geliştirme süresi alıyor. Dolayısıyla, daha düşük bir bütçeniz varsa veya zamanı geri ölçeklendirdiyseniz ve zaten geleneksel WordPress'te çözümleriniz varsa, henüz Başsız olmayabilirsiniz. Site yöneticilerinizin ön ucu değiştiren eklentileri yükleme konusunda gerçekten kontrole ihtiyacı varsa, henüz Başsız olmayabilirsiniz.

Ekibiniz gerçekten PHP'yi tercih ediyorsa ve JavaScript veya alternatif ön uçlar öğrenmek istemiyorsa, geleneksel WordPress'e de bağlı kalabilirsiniz. Bileşen tabanlı bir geliştirmeye veya bileşen tabanlı bir kitaplığa yatırım yapmadıysanız, bununla ilgilenmiyorsanız, geleneksel WordPress geliştirme iş akışlarına bağlı kalabilirsiniz.

Ve eğer geleneksel WordPress'inizdeki temel web hayati değerleriniz gerçekten iyiyse ve web sitenizin çok hızlı çalışmasını sağlamak için bakım maliyetleriniz çok düşükse, geleneksel WordPress'e bağlı kalabilirsiniz. Yani Başsız gitmenize gerek yok. Ama Headless'a geçmenin bazı takımlar için neden iyi olabileceğini düşündüğümü size göstereceğim.

Dolayısıyla, WordPress geliştirici deneyimine tekrar bakarsak, içeriğimizi büyük bir HTML yığını oluşturan bir alanda yayınlıyoruz. Ve bu ayrıntılı bloklara sahip olan Gutenberg editörünü kullanıyor olsak bile, sonuç büyük bir HTML yığınıdır. Ve ister Gutenberg'de ister geleneksel klasik editörde yayınlayalım, bu HTML parçası PHP aracılığıyla temamıza gönderilir ve HTML'mizi, CSS'mizi ve JavaScript'imizi yükleyen tek bir global sayfamız olur. Ve bu varlıklar sayfaya global olarak uygulanır.

Bu nedenle, WordPress geliştiricileri genellikle geliştirmemizi dosya türlerine göre ayırır, bu nedenle CSS'mizi sayfaya genel olarak uygulanan ayrı dosyalara koyacağız veya HTML PHP'de yazılacak ve ihtiyacımız olan verileri WordPress'ten ve ardından JavaScript'ten çekeceğiz. jQuery ile ayrı dosyalarda sık sık yazılabilir. Ve böylece bu üç şey, sayfayı oluşturmak için bir araya gelecek.

Sorun şu ki bunlar izole değiller, tüm sayfaya uygulanıyorlar. Yani bazen bir değişiklik yapabilirsiniz. Bu benim başıma geldi gibi. Bir keresinde yöneticimin isteği üzerine bir sitenin altbilgisindeki bir stilde değişiklik yaptım ve üç gün sonra, o geçiş kodu incelemesinden dolayı sitenin başka bir yerindeki stilin değiştiği bildirildi. Onu geçtik.

Aniden, sitedeki başka bir şey bozuldu ve bunun nedeni, CSS'nin küresel olarak uygulanması ve fark etmediğiniz şeyleri etkileyebilmesidir. Yine de yeni bir trend var, geçmişte – bilmiyorum – yedi, sekiz yılda bileşen tabanlı mimari olarak adlandırılabilir. Bu, uygulamamızın belirli parçalarını bileşenler adı verilen şekilde oluşturmamızı sağlar.

Ve JavaScript'imizi, HTML'mizi, CSS'imizi küçük parçalar halinde birleştirerek tek başına test edebiliriz ve böylece uygulamamızın parçalarını oluşturabiliriz. Birkaç endişe, biçimlendirme, JavaScript'ler, stiller ve daha karmaşık uygulamalar oluşturmak için bu bileşenleri bir araya getirebiliriz.

Ve böylece bileşen tabanlı geliştirme, karmaşık özellikleri daha küçük izole parçalara ayırmamıza olanak tanır ve bunları ayrı ayrı test edebilir, çalıştıklarından emin olabilir ve ardından birleştirilmesi gereken endişelerimizi birleştirebiliriz. Kullanıcı arayüzünün her diliminin belirli bir sorumluluğu vardır. Bu bir resim kartıysa, resmin belirli bir URL ile belirli bir boyutta oluşturulmasından sorumlu olabilir.

Bu yüzden işaretleme bağımlılıkları vardır. Stil bağımlılıkları vardır. Durum bilgili etkileşimlere sahip olabilir. Bunların hepsi o belirli bileşenle ilgilidir. Böylece işaretlememizi, JavaScript'imizi ve CSS'mizi tek bir yerde birleştirip test edebilir ve iyi çalıştığından emin olabiliriz. Ve bu nedenle, bu bileşenleri uygulamamız boyunca yeniden kullanabiliriz veya hatta bileşenlerimizi projeler arasında yeniden kullanabiliriz.

Yani bileşen kitaplıkları denen bir trend var. Material UI veya son tasarım bileşenleri gibi projeler var veya Chakra UI da popüler. Ve bu bileşenleri projeler arasında kullanabiliriz. Erişilebilir işaretleme gibi temel sorunları çözebiliriz. Ve bunlar için güncellemeler yapabilir ve bunları organizasyonumuzdaki birden fazla projede aynı anda uygulayabiliriz ve bu nedenle - bu nedenlerden dolayı, çok daha fazla güvenle daha hızlı yineleme yapabilir ve sevk edebiliriz.

Peki Headless WordPress'i nasıl kullanabiliriz? Daha önce de bahsettiğim gibi, WordPress'ten bileşenlere veri almanın iki yolu var. Biri REST API olacaktır. Biri WPGraphQL olacaktır. Arkadaşım Drake bir süredir Headless siteleri kuruyor, ben de ona sordum ve o da böyle dedi...

WPGraphQL'yi tercih ediyor. İşte bugün bunun hakkında konuşacağız. Peki WPGraphQL nedir? diye sorabilirsin. Herhangi bir WordPress sitesi için genişletilebilir bir GraphQL şeması ve API sağlayan ücretsiz, açık kaynaklı bir WordPress eklentisidir. O halde GraphQL nedir? Şey, bu bir grafik sorgulama dili.

Pekala, Jason. Hala ne dediğini anlamıyorum. Pekala, sana göstereyim. GraphQL'in çalışma şekli, istemci uygulamalarının sunucudan ne istediklerini belirten bir istek göndermesidir. Ve bir istek şuna benzer. Değerleri olmayan JSON anahtarlarına benziyor. Yani bu durumda, istek izleyici için soruyor ve bir izleyicide "ad" alanının döndürülmesini istiyoruz.

Ve GraphQL sunucusundan gelen bir yanıt şöyle görünebilir. Gerçek JSON verileri, anahtarları ve değerleri ve isteğin şekliyle eşleşir. Yani bu durumda, adı alıyoruz ya da izleyiciyi Jason Bahl adıyla alıyoruz. Böylece GraphQL, istemci uygulamalarının uygulama veri grafiğinden ağaçları çıkarmasına izin verir.

Ve bunun görsel olarak neye benzediği şuna benzer. Grafiğe girebiliriz, diyelim, bir görüntüleyici veya kullanıcı alanı veya bir düğüm ekleyebiliriz. Ve bu düğüm, Jason adı gibi bir özelliğe sahip olabilir. Ve bu düğüm, resim URL'si gibi bir özelliğe sahip olabilecek bir avatar gibi grafikteki diğer düğümlerle bağlantılara sahip olabilir.

Ve bu kullanıcının, o kullanıcının yazdığı gönderi gibi diğer düğümlerle bağlantıları olabilir. Ve bu gönderilerin kendileri bir başlık, merhaba dünya veya elveda Mars gibi özelliklere sahip olabilir. Ve bu gönderilerin, haber veya spor gibi kendi başlıkları olan kategoriler gibi grafikteki diğer düğümlerle bağlantıları olabilir. Ve bu kategorilerin, daha fazla gönderi gibi diğer düğümlerle bağlantıları olabilir. Ve bu gönderiler, öne çıkan resimlere vb. sahip olabilir. GraphQL ile parçalarını isteyebileceğimiz bu büyük veri grafiğine sahibiz.

Ve böylece araçları GraphQL yöneticisinde veya WordPress yöneticisinde kullanabiliriz. Bir sorgu oluşturabileceğim GraphiQL adında bir araç var. Ve burada alt seçimleri, adı, avatarı, URL'si olan Görüntüleyici alanını seçiyorum ve bunu yürüttüğümüzde, istediğimiz alanları alıyoruz ve görsel olarak bu sorgu biraz buna benziyor.

Grafiğe girdik ve bir kullanıcı istedik. Kullanıcının adını, avatarın URL'sindeki bağlı avatarı sorduk. Tüm bu veri grafiği elimizde mevcut, ancak yalnızca belirli bir veri kümesi istiyoruz ve yanıt olarak, o belirli gerilemeyi elde ettik. Ve böylece alabiliriz – artık bileşenleri kullanabiliriz.

Bu yüzden, bileşen tabanlı geliştirmenin faydalarından bahsettim ve bunu size uygulamalı olarak göstermek istiyorum. Ve bu benim sunumsal bileşen diyeceğim şey. Yani bu, sorumlu olan bir kart bileşenidir. Bu kartı bir resim ve bir başlık ile işlemek için tek bir sorumluluğa sahiptir.

Ve koda bakabiliriz ve biraz stil kontrolümüz olduğunu görebiliriz. Genişliği ayarlayabiliyoruz, istediğimiz görseli ve başlığı geçebiliyoruz. Böylece bu bileşeni projemiz boyunca yeniden kullanabiliriz. Ve bu bileşen ihtiyacımız olan tüm bağımlılıklara sahiptir. Oluşturulacak HTML'ye sahiptir. Stilleri var. Burada biraz stil kontrolümüz var. Fareyle üzerine gelme durumu ve benzeri gibi bazı durum bilgisi olan bileşenleri vardır.

Yani bu, yeniden kullanabileceğimiz izole edilmiş bir bileşen ve GraphQL ile şimdi WordPress yöneticisinde oluşturduğumuz sorguyu GraphQL kullanarak alabilir ve bunu getirebilir ve şimdi bir görüntüleyici kartı bileşenine sahip olabiliriz. Böylece sorgumuzu yazabiliriz, kart bileşenimizle birleştirebiliriz ve şimdi bileşeni tamamlar.

HTML'miz, CSS'miz JavaScript'imiz var. Ve veriler sayesinde artık istediğimiz verilerle oluşturacak bir şeyimiz var. Artık bunu uygulamamız boyunca kullanabiliriz ve GraphQL'nin fragmanlar adı verilen bir özelliği vardır ve bu, GraphQL sorgularımızı alıp yeniden kullanılabilir parçalara ayırmamıza olanak tanır.

Yani bu durumda, bir kullanıcı profili kart parçası oluşturuyorum ve adını, avatarını ve URL'sini belirtiyorum ve sonra bu parçayı daha büyük bir sorguda kullanıyorum. Yürüttüğümüzde beklediğimiz sonuçları alırız. Artık o parçayı alıp bir bileşene koyabiliriz. Artık Kullanıcı Profili Kartı adında farklı bir bileşenimiz var.

Bu kullanıcı profili kartı, bir kullanıcıyı her sorguladığımızda, bileşende kullanılacak avatarın adını, avatarını ve URL'sini almamız gerektiğini belirtir. Artık bu yeniden kullanılabilir bileşene sahibiz, uygulamamızın herhangi bir yerinde bir kullanıcıya sorsak, bu yeniden kullanılabilir kartı kullanıcının avatarı ve adıyla işlemek için gerekli verileri alabiliriz.

Ve böylece bu artık uygulamamızın daha büyük bölümlerinde kullanılabilir ve kullanılabilir. Yeniden kullanılabilir bir kullanıcı profili kartı bileşeninden içe aktardığımız parçayı kullanan görüntüleyici sorgusundan önce sahip olduğumuz sorgu burada. Ve sonra bunu bir görüntüleyici kartı bileşenine gönderiyoruz ve şimdi bunu uygulamamız genelinde yeniden kullanabiliriz.

Bu kullanıcı kartına veya yazar kartına dayanan uygulamamızın daha büyük bölümlerini yapabiliriz. Böylece artık başlıktan sorumlu olan blog başlığı bileşeni gibi birden fazla bileşene sahip olabiliriz. Kullanıcının profilini oluşturan yeni oluşturduğumuz bir kullanıcı profili kartımız olabilir. Uygulamamızın bu bölümü için işaretlemeden ve verilerden sorumlu olan bir içerik veya alıntı bileşenine sahip olabiliriz.

Ve evet, işaretlemeden, CSS'den ve bu uygulamayı oluşturmak için gereken verilerden sorumlu olan bu küçük bileşenleri oluşturabiliriz. Ve bunları birlikte oluşturabiliriz. Onları izole olarak test edebiliriz, ayrıca daha büyük birimler olarak da test edebiliriz. Böylece bunu çeşitli şablonlarda da kullanabiliriz.

Bu yeniden kullanılabilir bileşenleri, farklı yazarların olduğu bir blog gönderisi veya blog rolümüz için kullanabiliriz, ancak bunları oluşturmak için aynı bileşeni kullanabiliriz. Diğer arşiv sayfası için kullanabiliriz. WordPress şablon parçalarına çok benzer, Headless uygulamalarımızı küçük parçalara ayırabiliriz, ancak teknolojimizi bir araya getirme avantajını elde ederiz.

Bu biraz Headless WordPress geliştiricisinin bileşen tabanlı tasarım ve bunun faydalarını deneyimlemesi ile ilgili. Şimdi, özellikle Gutenberg söz konusu olduğunda, neden özellikle Gutenberg ile Başsız WordPress'i düşünürsünüz? Ekibiniz, muhtemelen Gelişmiş Özel Alanlar ve esnek alanlar ile zaten Headless WordPress kullanıyorsa ve editör deneyimini Gutenberg'i kullanacak şekilde güncellemek istiyorsanız, bu kesinlikle Gutenberg ile Headless'a geçmenizin bir nedenidir.

Yöneticide kullanılan bileşenlerden ve ön uçta kullanılan bileşenlerden yararlanmak istiyorsanız, Gutenberg ile Başsız çalışmayı düşünmek için iyi bir neden çünkü blok düzenleyicinin Gutenberg arka uç düzenleyicisi tamamen bileşen tabanlıdır. Yapılandırılmış girdiden yararlanmak isteyebilirsiniz. yöneticideki her bloğun yapılandırılmış alanları vardır.

Saha düzeyinde kontrol edebileceğiniz belirli nitelikleriniz var. Ayrıca, bu yapılandırılmış çıktının bileşenlerinize de gelmesinden faydalanmak isteyebilirsiniz. Bahsettiğim gibi, bileşenleri ve blokları projeler arasında yeniden kullanmak isteyebilirsiniz. Örneğin, erişilebilirlik ve projeler genelinde kullanmak istediğiniz belirli biçimlendirme endişeleri gibi şeyleri çözen, ajansınızın oluşturduğu bir blok kitaplığa sahip olmak isteyebilirsiniz. Ve sonra bunları yalnızca tek bir proje içinde değil, projeleriniz genelinde güncelleyebilirsiniz.

Bu, WordPress'teki benzer alt temaların ölçeklendirilmesinin zor olabileceği bir bölümdür çünkü her siteye gidip işaretlemeyi güncellemeniz ve her sitedeki diğer şeyleri güncellemeniz gerekir. Burada, blok kitaplıklarını NPM bağımlılıkları olarak kullanabilir ve bunları kuruluşunuz genelinde güncelleyebilirsiniz.

Şu anda, Gutenberg ile WordPress geliştirme durumu, arka uçta bileşen tabanlı bloklara sahip olmamızdır. Kendi özel bloklarımızı oluşturabilir veya temel WordPress bloklarını kullanabiliriz. Ancak PHP'deki çıktı, daha önce de belirttiğim gibi, büyük bir HTML yığınıdır ve bu nedenle, bu tek HTML bloğunu almaktan arka uçta ön uçtaki bileşenlere de aktarılan bileşenlere sahip olmaya nasıl geçebiliriz?

Bu nedenle, Gutenberg verilerini WordPress'ten bileşenlere aktarmak için bazı seçeneklere bakacağız. Yani bir seçenek, içeriği HTML olarak almaktır. Böylece WordPress içeriğimizi HTML olarak sorgulayabilir ve ardından bu HTML'yi bileşenlere ayrıştırabiliriz. Veya blokları GraphQL türleri olarak sorgulayabiliriz. Böylece, bir blok listesini sorgulamamıza izin verir, her blok bir bileşene eşleyebileceğimiz bir GraphQL tipi olacaktır.

Yani içerik HTML'dir. Bu, bugün WPGraphQL çekirdeğinde yapabileceğimiz bir şey. Blokları ayrı GraphQL türleri olarak sorgulamak istiyorsanız, şu anda iki seçenek var. Topluluk uzantısı olan Gutenberg için GraphQL uzantımız ve ardından kişisel olarak üzerinde çalıştığım bir beta eklentisi olan WPGraphQL Block Editor'ımız var.

Ve şimdi bu seçeneklere bakalım. WPGraphQL çekirdeğinde, içeriği HTML olarak sorgulayabilir ve bileşenlere ayrıştırabiliriz. Görünüşe göre gönderi gibi bir şeyi sorguluyoruz ve kimlik, başlık veya içerik gibi alanlar isteyebiliyoruz. Ve içerik büyük bir dize, büyük bir HTML parçası döndürecek ve sonra bu HTML'yi ayrıştırabilir ve farklı DOM düğümlerini farklı bileşenlere eşleyebiliriz.

wpgraphql.com'daki bu durumda olduğu gibi, soldaki bağlantı bunun gerçekten gerçekleştiği koddur. WPGraphQL'den döndürülen işaretlemeyi alıyorum ve ayrıştırıyorum, belirli HTML düğümlerini arıyorum ve onu React bileşenlerine dönüştürüyorum. Böylece, sözdizimi vurgulama yapan ve kullanıcıların Kopyala'yı tıklatmasına izin veren bu kod bloğu gibi etkileşimli şeylere sahip olabilirim ve ardından örneğin bir içindekiler tablosunu ayrıştırabilir ve oluşturabilirim. Yani bu bir yaklaşım. Ve bugün wpgraphql.com'da üretimde kullanıyorum.

Bu yola giderseniz göz önünde bulundurmak isteyebileceğiniz bazı şeyler, HTML yükleri tahmin edilemez olabilir. Düzenleyicilerin içeriğe ekleyebileceği yeni bir blok kitaplığı veya çeşitli HTML yüklemek gibi sunucudaki değişiklikler önceden tahmin edilemez. Bu yüzden ayrıştırmak çok zor olabilir. Değişiklikleri iç içe gözlemleyemezsiniz. Bir müşteri geliştiricisi olarak, neyin değiştiğini göremezsiniz, bu yüzden dikkate alınması gereken bir şey var.

Bu yaklaşımın, WordPress yöneticisi ve ön uç üzerinde çok sıkı kontrole sahip ekipler için en iyi sonucu verdiğini söyleyebilirim. Dolayısıyla, WordPress arka uç ve ön uç üzerinde çalışan tek bir kişi veya küçük bir ekipseniz, girdi ve çıktıyı biraz daha iyi kontrol edebileceğiniz için bu sizin için uygun olabilir.

Diğer seçeneklerden biri olan WPGraphQL for Gutenberg, topluluk tarafından sürdürülen bir eklentidir. Ve bu, içerik bloklarını, her bloğu kendi GraphQL türü olarak sorgulamanıza izin verecektir. Bunun çalışma şekli bir ayarlar sayfasıdır, şema olarak sadece bloklara girmeniz gerekir, bu Gutenberg'i görünmez bir iframe'de açar, blok kaydını JavaScript istemcisinden alır ve sunucuya gönderir.

Ve sonra, bloklarımızı belirli türler olarak sorgulamak için GraphQL'i kullanabiliriz ve daha önce gösterdiğim gibi parçaları kullanabiliriz ve bu parçaları, ön ucumuzdaki bileşenlerle eşleştirmek için kullanabiliriz. Yani bu bir seçenek. Bu eklentiyle ilgili bazı hususlar, blok kayıt defterindeki değişiklikler iç gözlemlenebilir, bu yüzden bu iyi bir şey.

Ön uç uygulama üzerinde çalışan ekipler, şemanın zaman içinde nasıl değiştiğini görmek için GraphQL iç gözlemini kullanabilir ve kullanabilecekleri büyük değişiklikler veya yeni alanlar olup olmadığını öğrenebilirler. Bu yaklaşımın çok kişili veya çok ekipli projeler için biraz daha iyi çalıştığını söyleyebilirim. WordPress yöneticisinde çalışan bir ekibiniz ve ön uçta çalışan farklı bir ekibiniz varsa, bu yaklaşım daha iyi sonuç verebilir. GraphQL şemasını, her iki tarafta da kullanılan bloklar arasında bir sözleşme olarak kullanabilirler.

Biraz ilginç olan bir şey, bahsettiğim gibi blokları iframe'e yüklemesidir. Ve bu nedenle, her durum için her zaman ölçeklenmez. Bu nedenle, blokları belirli bir sayfaya veya belirli bir şablona veya belirli bir gönderi türüne kaydederseniz, blok kayıt eşlemesini şemaya alma yöntemi bazı blokları kaçırabilir. Bu nedenle, her proje için ölçeklendirilmeyebilir.

Bir sonraki proje olan WPGraphQL Block Editor, şu anda üzerinde çalıştığım bir beta eklentisi. Bu ayrıca içerik bloklarını kendi GraphQL türleri olarak sorgulamanıza olanak tanır ve WPGraphQL for Gutenberg'e çok benzer, belirlediğimiz verileri döndüren parçalar yazabiliriz. Ve sonra bu parçaları ön uçtaki bileşenlerimizle birlikte kullanabiliriz.

Bununla ilgili bazı hususlar, bu bir beta eklentisidir, işte bu. Yapılandırılmış girdi ve yapılandırılmış çıktıdan yararlanırsınız. Ön uç geliştirici olarak, bu kesinlikle bir kazançtır. Block.json dosyasına kayıtlı bloklarla çalışır. Temel WordPress Gutenberg blokları bu dosyaya sahiptir ve bu nedenle bu, bu yaklaşımla çalışacaktır. Pek çok üçüncü şahıs, bloklarını bu şekilde kaydetmez, dolayısıyla bu blokları manuel olarak haritalandırmanız gerekir.

Bloklar ayrı ayrı düğümler olarak ele alınmaz. Blokları ayrı düğümler olarak ele almak isterdim, ancak genel bir kimlik yok, bu nedenle bu bloklara poster sayfası gibi daha büyük nesnelerin parçaları olarak erişmeniz gerekiyor.

Umarım Headless WordPress, Headless WordPress'in faydaları ve Headless WordPress'i Gutenberg ile kullanma hakkında bir şeyler öğrenmişsinizdir. Sizi bugün WPGraphQL'i denemeye davet ediyorum. Ücretsiz bir Atlas Sandbox hesabı için wpengine.com/atlas adresinden kaydolabilirsiniz. Ve sunumuma katıldığınız için teşekkür ederim. Yine, beni Twitter'da, jasonbahl'da veya ayrıca Twitter @wpgraphql'da bulabilirsiniz. Teşekkür ederim.