HTMX WordPress İçin Büyük Bir Fırsat Olabilir

Yayınlanan: 2024-05-10

Tarayıcıda zengin bir kullanıcı deneyimi oluşturmak, genellikle önemli miktarda JavaScript kodu gerektiren zorlu bir görev olabilir. Uygulamamızın ihtiyaçları ve hedefleri arttıkça JavaScript kodumuzun karmaşıklığı da artar. Bu nedenle geliştiricilerin JavaScript uygulamaları hakkındaki düşüncelerimizi ve yazma şeklimizi bu kadar sıklıkla gözden geçirmesi şaşırtıcı değil.

Son JS çerçevesinden bu yana geçen gün sayısı.

WordPress eklenti geliştiricilerinin durumu daha da kötü. Hedeflediğimiz ortam ne bizim kontrol ettiğimiz bir sunucu ne de sayfanın tamamı üzerinde tam kontrole sahip olan bir sunucudur. Bir WordPress eklentisinde JavaScript çerçevesini başarılı bir şekilde kullanmak çok mümkün olsa da, ölçeği ve karmaşıklığı amaçladığınız veya beklediğinizin ötesinde bir projeyle sonuçlanmak da son derece kolay olabilir.

Peki ya bu şekilde olması gerekmiyorsa? Bu yazıda modern web kullanıcı arayüzlerinin JavaScript ile nasıl oluşturulduğunu, geliştiricilerin karşılaştığı zorlukları ve HTMX'in sunduğu alternatifi inceleyeceğiz. Özellikle HTMX ve WordPress'in neden harika bir eşleşme olabileceğine bir göz atacağız.

Buraya nasıl geldik

JavaScript'ten önce tarayıcılar temelde sadece belge okuyucuları olarak yüceltildi. Bu nedenle, web'deki deneyimlerin çoğu 'çok sayfalı uygulamalar' veya kısaca MPA'lardı. MPA'lar, uygulamadaki her sayfa için bir tane olmak üzere birden fazla HTML belgesinden oluşan web uygulamalarıdır. Kullanıcı uygulamayı kullandıkça, kendisine farklı eylemler içeren farklı belgeler gösterilir.

MPA'ların oluşturulması çok basittir. Gezinme, diğer belgelere bağlanmak için <a> etiketleri kullanılarak yapılır ve kullanıcı girişi bir <form> öğesiyle yakalanabilir. Sunucu, bağlantı ve form isteklerine, ekranda gösterilen sayfayı değiştirerek yeni HTML belgeleriyle yanıt verir.

Muhtemelen çok aşina olduğunuz MPA'ya iyi bir örnek WP Admin'dir. Her yönetici sayfası, sunucuda çalışan WordPress PHP kodu tarafından oluşturulan HTML içeren bir belgedir. WordPress ayarları sayfaları gibi WP Admin'deki çoğu sayfa çoğunlukla sizin, yani kullanıcının gönderebileceği formlardan oluşur.

Tersine, tek sayfalı bir uygulama veya SPA, tek bir HTML sayfası kullanan bir uygulamadır. Gezinme ve kullanıcı girişi daha sonra JavaScript kodu tarafından gerçekleştirilir ve sayfanın tamamını değiştirmeye veya yenilemeye gerek kalmadan sayfanın bazı bölümleri yerinde dinamik olarak değiştirilir. Bu, daha sorunsuz ve daha duyarlı bir kullanıcı deneyimi sağlar.

Günümüzde birçok web uygulaması web arayüzleri için SPA'ları kullanıyor. RebelCode'da iki ana WordPress eklentimizin yönetici arayüzleri için SPA'lar oluşturduk: Spotlight ve Aggregator. WordPress'teki nispeten yeni site editörü, blok tabanlı yazı editörü gibi aynı zamanda bir SPA'dır.

Ödediğimiz bedel

SPA'lar, JavaScript ile yazılmış ve tarayıcıda çalışan kendi uygulamalarıdır. Kendi tanımları da onların en büyük uyarısıdır: Sunucu kaynaklarına anında erişimleri yoktur. Bu da SPA ile sunucu arasında bir iletişim kanalı kurmamız gerektiği anlamına geliyor.

Örnek olarak basit bir WordPress eklentisi oluşturalım. Bu eklenti sağlar
Kitapları yönetmek için basit bir CRUD kullanıcı arayüzü. Eklentinin sunucudaki dahili API'si şuna benzer:

 <?php function get_books(?int $count = null, int $page = 1): Book[]; function get_book(int $id): Book; function insert_book(Book $book): Book; function update_book(Book $book): Book; function delete_book(int $id): void;

Modern SPA arayüzümüzü oluşturmak için React gibi bir JavaScript çerçevesi kullanacağız; WordPress tarafından da kullanılan en popüler JavaScript çerçevesi. Bir yönetici sayfası ekleyerek başlayalım:

 <?php add_action('admin_menu', function () { add_menu_page('Books', 'Books', 'manage_options', 'books', 'books_page'); }); function books_page() { echo '<div></div>'; }

Sayfamız, kullanıcı arayüzünün geri kalanının işleneceği React uygulamamızın kökü olarak hizmet edecek tek, boş bir <div> öğesi oluşturacaktır.

 const rootEl = document.getElementById("books-app"); const root = ReactDOM.createRoot(rootEl); root.render(<BooksApp />); function BooksApp() { return ( <div> <h1>My Books</h1> ... </div> ); }

Peki veritabanında saklanan kitapları nasıl listeleyeceğiz? Bunu yapacak kod sunucuda olduğundan onu çağırıp sonucunu almanın bir yoluna ihtiyacımız var.

Bunu yapmak için sunucudan bir JSON API'sini açığa çıkarabiliriz. React uygulaması daha sonra API'mizin URL'sinden bir istekte bulunabilir, kitapları JSON formatında alabilir ve ardından listeyi oluşturabilir. Bu örnekte WordPress REST API'sine bir uç nokta eklediğimizi varsayalım:

 GET https://my-wp-site.com/wp-json/books { "books": [ { "id": 15, "title": "Mistborn", "author": "Brandon Sanderson", }, { "id": 44, "title": "The Hobbit", "author": "JRR Tolkien", }, ] }

Daha sonra kitapları getiren ve liste halinde görüntüleyen bir React bileşeni yazabiliriz:

 function BookList() { const [books, setBooks] = useState([]); const [isLoading, setIsLoading] = useState(true); const [error, setError] = useState(null); useEffect( function () { setIsLoading(true); fetch("https://my-wp-site.com/wp-json/books") .then((res) => res.json()) .then((data) => setBooks(data.books)) .else((error) => setError(error)) .finally(() => setIsLoading(false)); }, [setBooks, setIsLoading], ); if (isLoading) { return <div>Loading...</div>; } if (error) { return <div>Error: {error}</div>; } return ( <ul> <li> {books.map((book) => ( <a key={book.id} href={book.url}> {book.title} </a> ))} </li> </ul> ); }

Ancak bu çözüm çok saftır ve kaba bir kullanıcı deneyimi sağlar. Bileşenin bağlantısı kesildikten sonra durum değişikliklerini karşılamaz, yanıtı önbelleğe almaz, başarısız sorguları yeniden denemez veya eski durumun daha yeni durumun üzerine yazılmasını engellemez. Aslında, React efektinde fetch() yöntemini kullanma şeklimiz genellikle önerilmez.

Birçok yönden bu, geleneksel bir DKA'dan daha kötü olabilir. Bunu doğru bir şekilde yapabilmek için müşterimizde birkaç şeyi daha uygulamamız gerekecek. Veya daha gerçekçi olmak gerekirse 3. parti paketleri kullanın.

Ancak tüm bunlar, sırf kitap listesi oluşturmak için orantısız bir çaba gibi gelmeye başlıyor. Sorunsuz bir kullanıcı deneyimi oluşturmak için gerçekten bir JavaScript uygulaması ve JSON API oluşturmamız gerekiyor mu?

Bunu, kitap listesinin oluşturulmasının yalnızca birkaç satırlık PHP koduyla, herhangi bir bağımlılık olmadan gerçekleştirilebildiği MPA ile karşılaştıralım:

 <?php function render_books() { ?> <ul> <?php foreach (get_books() as $book): ?> <li> <a href="<?= $book->url ?>"> <?= $book->title ?> </a> </li> <?php endforeach; ?> </ul> <?php }

Ancak elbette bu adil bir karşılaştırma değil. Bu kitap listesi yalnızca statik HTML'dir; durum değişikliklerine veya kullanıcı girişine tepki vermez.

Kodumuzun veritabanına anında erişebildiği sunucuda HTML'yi oluştururken aynı zamanda SPA benzeri bir deneyim yaşamak istiyorsak, sunucu tarafından oluşturulan HTML'nin tarayıcıya giden yolu bulmasını sağlamanın bir yolunu bulmamız gerekir. ve önceki kitap listesini değiştirin. Ancak bunu herhangi bir JavaScript kodu olmadan başarmak şu anda imkansızdır, bu yüzden yine de kurşunu ısırıp JavaScript kullanmamız gerekir.

Ancak bunu kendimiz yazmamıza gerek yok.

HTMX'le tanışın

HTMX, öncelikle tek bir şey yapan küçük bir JavaScript kitaplığıdır: HTML'nin sunucudan yeni HTML istemesine izin vermek. Bunu, HTMX'e yeni HTML'yi nereden alacağımızı, neyle değiştireceğimizi ve değiştirmeyi neyin tetikleyeceğini söylememize olanak tanıyan yeni nitelikleri kullanarak yapıyor. HTML sunucumuz ile tarayıcıdaki sayfa arasında köprü görevi görür.

Mevcut sayfayı güncellemek için bir istemci JavaScript uygulaması oluşturmadığımız için bu, SPA'lar hakkında çok farklı bir düşünme şeklidir. Bunun yerine, HTMX'e belirli olaylar gerçekleştiğinde sayfanın nasıl değişmesini istediğimizi anlatmak için bazı HTML nitelikleri ekliyoruz.

HTMX olmasa bile, çok sınırlı da olsa, yalnızca HTML kullanarak ekranda gösterilenleri zaten değiştirebilirsiniz. Bu HTML özelliğine zaten aşinasınız: mütevazı <a> bağlantı öğesi.

 <a href="https://my-wp-site.com/books">View books</a>

Bir bağlantı öğesi, tarayıcıya gezinmeyi gerçekleştirmek için gerekli olan tüm bilgileri verir. Tıklandığında, tarayıcı öğeden href alır, bu URL'de bir istekte bulunur, yanıtı indirir ve HTML içerdiğini varsayarak sayfanın içeriğini yeni HTML ile değiştirir.

<form> öğesi, HTML'nin nasıl yeni HTML isteyebileceğinin başka bir örneğidir.

 <form action="/contact.php"> <label> Your message: <input type="text" name="message" /> </label> <button type="submit">Send message</button> </form>

Bu sefer tarayıcı, formdaki tüm girişlerden değerleri toplar, bunları sunucuya gönderir, yanıtı indirir ve ekrana dönüştürür.

Neden yalnızca <a> ve <form> HTTP istekleri gerçekleştirebilsin? Neden yalnızca ekranın tamamını değiştirebilmelisiniz?

HTMX'in GitHub benioku dosyasından

HTMX bunu değiştiriyor.

 <a href="https://my-wp-site.com/books" hx-target="#books"> View books </a> <div></div>

HTMX hx-target özelliğiyle, bağlantıya tıklamak artık https://my-wp-site.com/books adresinden gelen yanıtı "books" kimliğine sahip öğenin içine yerleştirecektir. Elbette burada amaç bir sayfayı diğerinin içine yerleştirmek değil. Sunucumuzun tam sayfayla yanıt vermesine gerek yoktur ve bunun yerine yalnızca bir HTML parçasıyla yanıt verebilir.

Sunucumuzdaki HTML parçalarını açığa çıkararak ve HTMX'e bu parçaların nasıl, nereden ve ne zaman alınacağını söyleyerek, herhangi bir JavaScript olmadan, sunucunun tam kontrole sahip olduğu SPA benzeri bir web uygulaması oluşturabiliriz. Bir anlamda HTML bizim yeni JSON'umuz oldu.

Tek yapmamız gereken HTMX betiğini sayfamıza yüklemek:

 <script src="https://unpkg.com/[email protected]"></script>

(Yukarıdaki kod güncel olmayabilir, talimatlar için HTMX belgelerine göz atmayı unutmayın).

Başka bir örneğe bakalım:

 <button hx-get="/button/off" hx-target="this" hx-swap="outerHTML"> Turn off </button>

Burada çok daha fazlası oluyor, o yüzden hadi parçalara ayıralım:

  • hx-get düğme tıklandığında GET isteğinin gönderileceği URL'yi belirtir.
  • hx-target="this" HTMX'e tıklanan düğmeyi yanıtla değiştirmesini söyler.
  • hx-swap="outerHTML" HTMX'e yalnızca içindekileri değil, düğmenin tamamını değiştirmesini söyler.

Hepsi bir arada, bu HTMX'e şunları söylüyor:

Düğmeye tıklandığında /button/off bir GET isteği gönderin ve bu düğmeyi yanıtla değiştirin.

Diyelim ki sunucu /button/off aşağıdaki HTML ile yanıt veriyor:

 <button hx-get="/button/on" hx-target="this" hx-swap="outerHTML"> Turn on </button>

Farkı görebiliyor musun? hx-get özelliği artık /button/on işaret ediyor ve düğmenin içindeki metin artık "Aç" oluyor. Bu buton tıklandığında, o da /button/on gelen yanıtla değiştirilecektir. Tahmin edebileceğiniz gibi, geçişimizi tamamlamak için sunucunun orijinal düğmeyle yanıt vermesini sağlayabiliriz!

Herhangi bir öğenin sunucudan yeni HTML istemesine ve bu HTML'nin nereye gideceğine karar vermesine izin verme şeklindeki bu basit fikrin oldukça güçlü olduğu ortaya çıkıyor. Sekmeler oluşturabilir, canlı sonuçlarla arama yapabilir, ilerleme çubukları ve daha fazlasını yapabiliriz.

Lehte ve aleyhte olanlar

Çoğu JavaScript çerçevesinden farklı olarak HTMX, istemci uygulama kodumuzun derlenmesini ve paketlenmesini gerektirmez. Bu tek başına büyük bir faydadır; Özellikle TypeScript, JSX, CSS ön işlemcileri vb. gibi daha egzotik özellikler ve kitaplıklar tanıtmaya başladığınızda, JavaScript derleme sistemlerinin kurulumu ve bakımı oldukça zor olabilir. Orta ve büyük ölçekli ekiplerin Bu göreve adanmış bir veya daha fazla üye.

Bir diğer bariz fayda ise ayrı bir istemci uygulamasının olmamasıdır. İhtiyacımız olan tek şey HTML ile yanıt veren bir HTTP sunucusu olduğundan, istediğimiz herhangi bir programlama dilini kullanabiliriz. Ekibinizin modern JavaScript'e aşinalığı yoksa veya iki uygulama oluşturmayı haklı çıkaracak kadar büyük değilse, bu sizin için büyük bir satış noktası olabilir. Eklentinizin tüm yönleri için PHP'yi kullanabileceğiniz için, bir WordPress eklenti geliştiricisiyseniz bu özellikle cazip gelebilir.

Ancak belki de en önemli fayda, uygulamanızın arka ucu ile ön ucu arasında artık bir API'ye ihtiyacınız olmamasıdır. Bu, geliştirme süresinden büyük miktarda tasarruf sağlamanın yanı sıra hata üretebilecek kod miktarını da azaltabilir ve bu da uzun vadede zaman tasarrufu sağlar.

Ancak HTMX kullanmanın herhangi bir JavaScript yazmanıza gerek kalmaması anlamına geldiğini varsayacak kadar saf olmamalıyız. Sürükleyip bırakma, grafikler, renk ve tarih seçiciler vb. gibi şeyler için hâlâ bir miktar JavaScript gerekebilir. Yine de SortableJS ve Floating UI gibi çerçeveden bağımsız çözümleri her zaman kullanabiliriz. Ayrıca, web standartları yeni <dialog> öğesi gibi yeni HTML öğeleriyle gelişmeye devam ettikçe gelecekte JavaScript'e daha az ihtiyaç duyabiliriz.

İkinci olarak, PHP, ironik bir şekilde, bunu yapmak için oluşturulmuş olmasına rağmen HTML şablonlama konusunda pek iyi değil. Etiket sözdizimi aşırı derecede ayrıntılıdır ve HEREDOC dize sözdizimi, dize enterpolasyonu için sınırlı desteğe sahiptir.

Son olarak, WordPress'te bir uç nokta oluşturmak çok kolay değildir. Önceki örneklerdeki kitap eklentisini düşünün. Sunucuda HTML biçiminde kitap listesiyle yanıt veren bir yola ihtiyacımız var. Bu uç noktayı nasıl kaydederiz?

  • init veya admin_init eylemi sırasında bir GET parametresi mi tespit edildi?
  • Yönetici Ajax API'sini mi kullanıyorsunuz?
  • Bir REST API uç noktası kaydedilsin mi?
  • Özel bir yeniden yazma kuralı eklensin mi?

Pek çok seçenek var ama hiçbiri bunu olması gerektiği kadar basitleştirmiyor.

HATEOAS

Önceki örneğimizde gözden kaçırılması çok kolay olan ince bir ayrıntı var ve ona dikkat çekildiğinde muhtemelen bariz görünecektir.

HTML'yi sunucudan aldığımızda, sayfadaki düğme ya AÇIK değişkenidir ya da KAPALI değişkenidir. Ekranda hangisinin gösterildiğine bağlı olarak tıklama eylemi farklı olacaktır.

Bu nedenle tarayıcının uygulamamızı anlamasına gerek yoktur. Normalde tüm davranışları açıkça programlamak için JavaScript kodunu vererek tarayıcının anlamasını sağlardık . Artık elimizde yalnızca HTML var ve tarayıcının, uygulamamızın nasıl davrandığına veya durumunun ne olduğuna dair önceden bilgiye ihtiyacı yok. Sadece uygulamamızın durumunu kodlayan HTML'yi ekranda görüntülemesi gerekiyor.

Bu mimari türü, 'Uygulama Durumunun Motoru Olarak Hipermedya' anlamına gelen HATEOAS olarak bilinir. Durum aktarımı için ortam olarak hipermedyayı kullanan özel bir REST mimarisi türüdür ve aynı hipermedya, kullanıcının uygulamayı yeni durumlara yönlendirdiği arayüz haline gelir.

Daha fazla bilgi edinmek istiyorsanız, HTMX web sitesinde bu konuyla ilgili harika makaleler, denemeler ve konuşmalar koleksiyonu bulunmaktadır. Bu makalenin bu amaçları doğrultusunda, HTMX'in WordPress geliştiricileri için neden önemli olabileceğine geçelim.

HTMX <3 WordPress

WordPress dev, yekpare bir PHP sunucusudur. WordPress eklentileri de öncelikle PHP ile yazılmıştır. Hooks API ve Veritabanı API'si gibi WordPress tarafından sağlanan PHP API'lerini kullanarak siteye yeni işlevler ekleyebilirler. Bu API'ler JavaScript'te mevcut değildir, bu nedenle eklenti geliştiricileri, eklenti kodlarının mümkün olduğunca çoğunu sunucuda tutmak istemelidir. HTMX'i kullanmak için bir motivasyon varsa, işte budur!

HTMX birçok açıdan WordPress için tasarlandı. Daha doğrusu WordPress gibi uygulamalar için; onları sunucu API koleksiyonlarını geride bırakmaya zorlayan yabancı bir dilin yükünü almak istemeyen uygulamalar. Özellikle durumu hipermedya kullanarak aktarmanın yeterli olacağı durumlarda değil.

WordPress eklentileri için iyi kullanıcı arayüzleri oluşturmayı kolaylaştırmak, eklenti ekosistemi üzerinde çarpıcı bir etkiye sahip olabilir. Ücretsiz eklentilere sahip geliştiriciler, kullanıcıları için daha iyi kullanıcı deneyimleri oluşturmayı daha uygun bulabilir ve daha küçük ekipler, kazanılan zamanla özellikleri daha hızlı bir şekilde yineleyebilir. Bu, daha büyük bütçelere sahip büyük ekiplerin ağırlıklı olarak hakim olduğu bir pazarda daha küçük eklentilerin daha rekabetçi olmasına yardımcı olabilir.

Daha büyük eklentiler de özellikle ilginizi çekebilir. JavaScript uygulamaları katlanarak hızla büyüyebilir. HTMX, bu eklentilerin büyük JSON API'lerini ve JavaScript uygulamalarını kaldırmasına ve WordPress API'lerine tam erişime sahip, yalın bir HTML sunucusunu yerinde bırakmasına olanak tanıyabilir.

Son düşünceler

Bir süredir HTMX ile uğraşıyorum, onu PHP ve Go ile birlikte kullanıyorum. Web üzerinde kullanıcı arayüzleri oluşturmak için ilgi çekici bir alternatif ve uygulama durumunu yönlendirmek için hipermedyanın kullanılması konusunda ikna edici bir argüman sunar.

Bir eklenti geliştiricisiyseniz HTMX'e mutlaka göz atın. Bu makalede sadece yüzeysel bir çalışma yaptık ve belgeler çok sayıda örnekle çok iyi yazılmış. Ayrıca HTMX'in kutudan ne kadar çok şey çıktığı göz önüne alındığında şaşırtıcı derecede kısa. Birkaç dakika içinde HTMX ve PHP'ye başlayabilirsiniz.