UI Geliştirmede Programlama Dili Değiştirmek Zorunda mıyım?
UI Geliştirmede Programlama Dili: UI geliştirme iddiası ne anlatıyor? UI Geliştirmede Programlama Dili kapsamında, Sıradan uygulama kodunda değerler yaratıyorum, bunları işlevlere aktarıyorum ve durumları ayırt ediyorum. Daha sonra Web kullanıcı arayüzü başlar ve bazen tüm dünya…
UI Geliştirmede Programlama Dili: UI geliştirme iddiası ne anlatıyor?
UI Geliştirmede Programlama Dili kapsamında, Sıradan uygulama kodunda değerler yaratıyorum, bunları işlevlere aktarıyorum ve durumları ayırt ediyorum. Daha sonra Web kullanıcı arayüzü başlar ve bazen tüm dünya değişir. Bileşen. Kancalar. JSX. Mağaza. Yaşam döngüsü. Abonelik. Bütün bunlar nedenlerden dolayı var. React ve Vue’yu yıllardır kullanıyorum, dolayısıyla bu hepsinin ortadan kalkması gerektiği anlamına gelmiyor.
UI Geliştirmede Programlama Dili kapsamında, Ancak bir noktada şunu merak etmeye başladım: Yaptığım şey kullanıcı arayüzüne dönüştüğü anda neden farklı bir programlama dinine katılmak zorundayım? Bir bileşen sadece bir fonksiyon olamaz mı?
UI Geliştirmede Programlama Dili kapsamında, Seseragi’nin Web Kullanıcı Arayüzü Turunda, küçük bir kullanıcı arayüzü parçası sıradan bir işlev olabilir: fn durum modeli: Model -> html.Html = html.p { kimlik: “durum”, rol: “durum”, çocuklar: model.status } Modeli alır ve Html değerini döndürür. İşte bu. Burada özel bir “bileşen bildirme” sözdizimi yoktur. Sonucu Html olan sıradan bir fonksiyondur. Bu çok hoşuma gitti.
Tasarım ve teknik ayrıntılar
Html sadece bir değer olamaz mı? Aynı fikir yukarıya doğru devam ediyor: fn sayfa modeli: Model -> html.Html = html.main { sınıf: “mx-auto max-w-xl p-4”, çocuklar: form modeli } html.main şablon dilinde bir kaçış yolu değildir. Sahne benzeri kısım bir plaktır. Çocuklar bir değerdir. Ortaya çıkan html.Html da bir değerdir.
Bu, onu sıradan bir işleve taşıyabileceğim, eşleşmeden döndürebileceğim, diğer değerlerle birleştirebileceğim ve genellikle zaten kullanmakta olduğum dili kullanmaya devam edebileceğim anlamına geliyor. Bence istediğim şey “kullanışlı bir UI DSL”den ziyade, kullanıcı arayüzüne kadar çalışmaya devam eden daha sıradan dil özellikleriydi.
Eylem de sıradan verilerdir Turdaki form aşağıdaki gibi değerleri kullanır: DraftChanged String. SabitlendiDeğiştirildi Bool. Gönderildi. Özel bir olay sistemi tipinin içinde saklı değiller. Bunlar sıradan veri oluşturuculardır, dolayısıyla sıradan eşleşme bunları halledebilir. Kodun yalnızca bu kısmına baktığınızda Web kullanıcı arayüzüne pek benzemeyeceğini görürsünüz. Bu benim için bir özellik.
Bugünden bakınca ne kadar güvenilir?
Durumu ve Eylem kodunu diğer makalelerde ele alacağım, bu nedenle form örneğinin tamamını buraya tekrar yapıştırmayacağım. Her makale aynı görünene kadar aynı dev örneği tekrarlamak asıl amacı boşa çıkaracaktır. Durum değişirse, Signal yapın Elbette ki bir kullanıcı arayüzü bir kez oluşturulup sonsuza kadar donmaz. Girişler değişir. Düğmeler tıklanıyor. Devlet hamleleri. Signal’in göründüğü yer burasıdır.
Ancak Signal’in tamamen ayrı bir dünya görüşüne sahip “UI çerçevesinin mağazası” olmasını istemedim. Bir değer zamanla değişiyorsa, zamanla değişen bir değeri modelleyin. Kavramsal olarak: Model ↓ Sinyal ↓ sıradan işlevli harita ↓ Sinyal<Html> ↓ DOM Sorumluluklar farklıdır. Model ve Signal aynı şey değildir. Html ve DOM aynı şey değildir.
Ancak her sorumluluk sınırının kullanıcı için bir programlama modeli sınırı olması gerekmez. Seseragi i oluşturabildiğinde React’ı yeniden oluşturmaya çalışmıyorum Etkileşimli Web kullanıcı arayüzünün React veya Elm ile karşılaştırılması kaçınılmazdır. Bu karşılaştırmalar faydalı olabilir. Ama “Bir React alternatifi oluşturmak istiyorum” diye başlamadım. Seseragi’nin zaten veri türleri vardı. Eşleşmesi vardı.
Okuyucu için pratik anlamı
Sıradan işlevleri vardı. Etkisi vardı. Daha sonra Signal’e tıklayın. Daha sonra değer olarak Html. Bunları birbirine bağladım ve sonunda bir Web uygulaması ekrana taşındı. Bu emir benim için önemli. Dilin üzerine bir çerçeve yerleştirdiğimden ziyade, geliştirme deneyimi çerçeveye benzeyene kadar sıradan dil özelliklerini kullanmaya devam ettiğimi hissediyorum.
Şu anda projenin en tuhaf ve en ilginç kısımlarından biri bu. Oyun Alanındaki formu deneyin https://seseragi.vercel.app/tour/ https://seseragi.vercel.app/ Turun Web Kullanıcı Arayüzü / özellik durumu bölümünde devam edin ve gerçek bir form örneğiyle etkileşime girebilirsiniz.
Değiştirilecek iyi şeyler: başka bir Eylem ekleyin Model’e başka bir alan ekleyin formu gönderdikten sonra durumu değiştirin, formu daha küçük işlevlere bölün, oluşturulan çıktıyı eşleşmeyle değiştirin Özellikle, kullanıcı arayüzünü daha küçük işlevlere bölmeyi deneyin. Bunu yaparken dikkate alınması gereken ekstra bir “bileşen mekanizması” yoktur.
Yalnızca işlevleri bölüyorsunuz ve kullanıcı arayüzü oluşturmaya devam ediyor. Bu beklediğimden çok daha iyi hissettiriyor. Halen deneyseldir. Seseragi’nin Web Kullanıcı Arayüzü ve çalışma zamanı hâlâ gelişmektedir ve Oyun Alanı da onlarla birlikte gelişmektedir. buna söz veremem tam yüzey sözdizimi bundan altı ay sonra aynı görünecek. Ancak şu anda üzerinde çalışmanın ilginç olmasının nedeni de budur.
Başladığım soru şuydu: “Kullanıcı arayüzü neden dili farklı hissettirmeli?” Şu anki Seseragi cevabı şaşırtıcı derecede sevdiğim bir şeye yaklaşıyor. Buradan itibaren çoğunlukla kullanmaya devam etmem gerekiyor. Ve bir şey çirkin gelmeye başladığında onu değiştirin. Bu proje aşağı yukarı bu şekilde çalışıyor.
İlgili yazılar
- Photoroom AI ile Ürün Fotoğraflarınızı Profesyonel Hale Getirin
- Uygun Fiyatlı Baseus Bowie MC2 Kulaklıklar: Bass ve Konforu Bir Arada
Ek okuma: MDN Web Docs
Editörün Notu
Kullanıcı arayüzü geliştirmede programlama dili değişikliği zorunlu değildir; sade fonksiyonel yaklaşımlar, karmaşık yapıları basitleştirerek daha anlaşılır ve sürdürülebilir kodlar yazmanıza olanak sağlar. Bu sayede, UI bileşenleri doğrudan işlevsel mantığınızla uyumlu hale gelir.
