FRONTEND KAPSAM
Bileşen Odaklı UI(Kullanıcı Arayüzü) Geliştirme
Bu yazıda Brad Frost yazdığı Atomic Design kitabı ile Tom Coleman yazdığı Component Driven Development üzerinden yeni Frontend Geliştirme tekniklerinden bahsetmek istiyorum.
Web uygulamalarının Native (Win32, MFC, Swing) ortamlardaki kompleks UI versiyonlarının tarayıcı üzerinde çalışabilecek hale gelmesi ve SPA(Single Page Application) daha sonrasında JAMstack yapısının gelişmesi bizim UI bileşenlerinin yapısının kütüphane/framework (Angular,Ember,React, Vue, Svelte …) birlikte evrimleşmesine sebep olmuştur.
Bu konuda UI Bileşenleri Nasıl Evrimleşti ? BackboneJS → ReactJS → Vue Composition API/Svelte/React Hook yazımı okuyabilirsiniz.
Tabi bu evrimleşmeyle birlikte Bileşen Odaklı yazılım geliştirme mantıkları ve araçları ortaya çıkmaya başladı. Örneğin;
- Component Explorer (Bileşen Gezgini): Bağımsız bileşenler üreterek bu bileşenlerin farklı state göre çizimlerini direk bu araçlar üzerinden test edip görüntülemenizi sağlayan araçlar. React için (Storybook, React Styleguidist , React Cosmos …).
- Design System: Birçok büyük firma Invision, Salesforce, Atlassian vb.. firma birçok proje ve uygulama geliştiriyor. UI için ortak bir dil olması gerekiyor . Temelde Color, Typography, Sizing and spacing, Imagery ile bir tasarım dili oluşturulması ve bunlar ile bileşen, sayfa ve geçişlerin(animasyonların) tasarım bütünü diyebiliriz. A comprehensive guide to design systems — Invision
- Component Based Mimari: Bu konuda Brad Frost yazmış olduğu Atomic Design kitap ve Tom Coleman yazmış olduğu Component Driven Development bu tarz yapılar oluşturmak için referans oluşturmaktadır.
Bu yazıyı 2018'de yazdığım 2 tane yazının devamı olarakta görebilirsiniz.
Atomic Design — Brad Frost
Bu yaklaşımda web uygulamanız kimyasal yapılarla benzerlik kullanarak anlatır.
Atoms: Web sayfasını oluşturan en küçük elemanlardır. Daha fazla parçalanamazlar. HTML tags ; label, input, button, div, canvas … buna örnektir
Molecules: Atomların bir araya gelerek oluşturdukları küçük bileşenlerdir. Örneğin bir arama molekül oluşturmak istiyorum;
- Label, Input, Button birleştirerek bu molekülü oluşturabilirim
- Label kullanıcıya bu bileşenin nerede aradığını, Input arama yapmak istediği kelimeyi gireceği ortamı, Button ise arama işlemini tetiklemesini sağlar
Burada moleküllerin sadece bir iş yapması ve onuda iyi yapması üzerine tasarlanmalıdır.
Organisms: Birden fazla molekülün, bazen aynı türdeki molekül gruplarının tekrar ederek oluşturdukları yapılardır. Örneğin; NavigationBar, Table, ListItems vb..
Templates: Bir veya birden organizma/molekülün layout üzerindeki yerleşim yapısıdır.
Pages: Template belli veri ile doldurularak gösterildiği gerçek sayfadır.
Atomic Design , design system oluşturabilmek için açık bir metodoloji sağlar. Müşteriler ve ekip üyeleri, önlerinde atılan adımları gerçekten görerek design system konseptini daha iyi anlayabilirler.
Atomik Design bize soyuttan somuta geçme imkanı sağlar. Bu sayede, tutarlı ve ölçeklenebilir, ve gerçek zamanlı bileşenlerin son halini bağlam içerisinde görebilme imkanı sunar. Büyük parçalar içerisinden bileşenleri parçalayıp ortak kullanmak yerine en baştan lego yapılar üzerinden sistemler kurmamıza olanak tanır.
Component Driven Development — Tom Coleman
Günümüz pratiklerinde artık UI modüler bileşenler olarak aşağıdan yukarıya doğru tasarlayarak geliştirilmektedir. Bu en ufak parçaların birleştirerek bir üst seviye bir bileşen ve bunlarıda birleştirerek daha üst seviye bileşenler oluşturabilme yapısıdır diyebiliriz. Aşağıdaki resimde biraz önce bahsettiğim Atomic Design benzeri bir mantığı görebilirsiniz
Component → Combine Components → Assemble Pages → Integrate Pages..
Bişelen Tipi Geliştirmeye Neden İhtiyaç Duyarız. (Avantajları)
- SaaS ekosisteminin büyümesi, verilen hizmet arayüzlerinin giderek daha fazla kompleks hale gelmesine ve farklı farklı cihazlarda her ortama uygun şekilde farklı deneyimler sunmayı gerektirmektedir. Bundan dolayı bileşenleri bağımsız olarak oluşturup test edebilmek yazılım geliştiricilere büyük avantajlar sağlar.
- Günümüz pratikleri monolitik hantal yapılar yerine mikro-servis, dağıtık şekilde ufak servisler aracılığıyla uygulamalar geliştirmeyi hedefler. Bileşen bazlı UI ekranları yapmakta bunlarla benzer şekilde evrimleşmiştir. Burda büyük bir ekosistem oluşmuştur. Bunlara direnip kendi yapılarınızı devam ettirmeniz teknolojiyi yakalayamayıp, bu fırsatlardan faydalanamamanız anlamınada gelir. Tabi bu aynı zamanda geliştiriciler üzerinde büyük bir baskıda oluşturur.
Bu konuda “Teknolojinin Geliştiriciler Üzerindeki Baskısı” yazımı okuyabilirsiniz.
- Nasıl yazılımda örüntüler var ise UIX (UI design) konusunda da örüntüler bulunur. Bir uygulamanın çalışması benzer özellikleri ve yapıları içerir. Her üründe bir SignUp, SignIn, MainPage, ChatApp, vb.. ortak bileşenler ve o işin ana yapısını içeren listeleme, raporlama ve girdi ekranları bulunur. Bunlar için her sayfayı ayrı ayrı tekrar tekrar kodlamak yerine ortak tekrar kullanılabilir bileşenler oluşturarak geliştirmemiz. Hem ilgili projede hemde şirketin diğer projelerinde işimizi rahatlatacaktır.
- Kullanıcı arayüzleri büyüdükçe , bileşen sayısı ve bunlar arasındaki etkileşim arttıkça daha kırılgan hale, hatayı bulmazı düzeltmesi daha zor ve zahmetli bir hale gelir. Olabildiğince sistemi küçük modüler yapılarda yapıp , bunlar üzerinde bir hata bir problem olduğunda o parçayı ele alıp tek başına orada hatayı düzeltmek, hem işleri kolaylaştıracak, hem de daha sağlam ve esnek kullanıcı arayüzleri oluşturmanızı sağlayacaktır.
Böyle Güzel Bir Ortam Vardı da Neden Geçmişte Bu Yöntem Bu Kadar Popüler Değildi ?
Aslında Bileşen Tabanlı UI tasarımı bizim çok eskiden 2000 lerde Java’da Object Oriented Design Pattern ile yaptığımız çalışmalarda da vardı. Ama bugünkü halinde değildi çünkü Ekosistemde günümüzde yer alan birçok araç o günlerde mevcut değildi. Micro-servis trendi ile birlikte bu micro -servislerinizi çalıştıracak Container(Docker) Bulut altyapıları yoktu, Ekiplerin yapısı ve yazılım geliştirme metodları çevik değildi.
Günümüzde ise durum bunun tam tersi ekosistemde bu işleri yapabilmeniz için araçlar, kütüphaneler ve yetişmiş insan kaynağı mevcut durumda.
Örneğin Tasarım için (Design System) oluşturmak için bir sürü araç bulunuyor. Bunlar hem sistemi mockup geliştirmenize imkan sağlıyor. Hemde Tasarımcı, Geliştirici, Ürün Yöneticisi ve Müşterileri birbirine yaklaştırıyor (Mockup detayını bu yazımdan okuyabilirsiniz Sketch, Wireframe, Mockup, Prototype arasındaki fark nedir?)
Tasarım İle mühendisliği Birbirine yaklaştıran Tasarım araçlarından bazıları
Bu tasarımlara göre bağımsız bileşen geliştirmeyi sağlayan kütüphane ve framework’lerden bazıları;
Geliştirdiğimiz bileşenleri bağımsız bir şekilde test etmek, birbirleri ile birleştirip uygulama olmadan çalıştırıp denememizi sağlayan araçlardan bazıları;
Özetle gününüz ekosistemi bileşen tabanlı UI geliştirmek için hazır ve her geçen gün bu konuda kendisini biraz daha geliştiriyor.
Düşünceler
Bileşen tabanlı sistemler sistemin hızlı bir şekilde gelişmesi , ölçeklenmesi için büyük avantajlar sunar ama bu demek değildir ki bileşenleri hazırla al bunları sistemine entegre et kullan. Burda daha business/iş mantığını yazmanız gereken birçok durum olacaktır. Bu iş mantıklarını uygulama geliştirirken bileşenlerin dışarısına çıkarmanız o kadar da basit olmayacaktır. Her ne kadar bileşen yapısı props ve state bağımlı olsada bileşenlerin dışarıda bu şekilde soyutlamak fonksiyonel programlardaki Pure Function mantığına benzer bir şekilde buraya getirip Pure Component şekilde tasarlamanız mümkün olmayacaktır. Büyük sistemler tasarlarken iş mantıkları ve App State yönetilmesi sizi en çok zorlayacak konulardan birisi olacaktır. Bu aşamada Redux kullanımı, High Order Component kullanımları bağımsız bileşenler oluşturabilmeniz için size imkan sağlar. HOC benzeri davranış paylaşımı için Hook kullanarak bileşenleri olabildiğince bağımsız şekilde tasarlayabilirsiniz.
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
