Atomik Tasarımın İki Kenarlı Kılıcı

Modern web sitelerinin karmaşıklığı son birkaç yılda önemli ölçüde arttı. Yüksek kaliteli, endüstri standardı tasarımlara yönelik artan talep, ön uç geliştiricilerin karşılaştığı zorlukları daha da yoğunlaştırıyor.

Günümüzde ön uç uygulamaların bile geliştirme sürecini kolaylaştırmak için bazı mimari hususlara ihtiyacı var. Bir önceki yazımda yan projem üzerinde çalışırken temiz mimari yaklaşımını ön uç uygulamalarda uygulama deneyimimi paylaşmıştım.

Bu makalede, aynı projedeki deneyimlerimden yola çıkarak atom tasarımı yaklaşımını daha derinlemesine incelemeyi amaçlıyorum. Avantajlarını ve dezavantajlarını tartışacağım ve farklı senaryolardaki kullanışlılığını değerlendireceğim.

Tasarım sistemlerine ilişkin arka plan

Başlangıç olarak tasarım sistemi kavramını inceleyelim. Tasarım sistemleri, ekiplerin birden fazla platformda tutarlı kullanıcı arayüzleri tasarlamasına ve geliştirmesine olanak tanıyan yeniden kullanılabilir bileşenlerin, yönergelerin ve ilkelerin kapsamlı bir koleksiyonudur.

Hem tasarımcılar hem de geliştiriciler için tek bir gerçek kaynağı olarak hareket ederek bir ürünün görsel ve işlevsel yönlerinin yerleşik marka kimliğine uygun olmasını ve bunlara bağlı kalmasını sağlarlar. Tasarım sistemi uygulamalarının örneklerini araştırmakla ilgileniyorsanız, aşağıdakileri incelemeyi düşünün:

• Karbon tasarım sistemi
• Grommet tasarım sistemi

Tasarım sistemleri konusuna daha derinlemesine dalmak istiyorsanız bu makaleye göz atmanızı öneririm. Bu konuyu ayrıntılı olarak, bu çalışma kapsamında bizim için gerekli olmayan detayları anlatmaktadır.

Atomik tasarım tasarım sistemlerinden nasıl türetilir?

Tasarım sistemlerinin temeline dayanan atom tasarımı, yeniden kullanılabilir bileşenlerin ve yönergelerin organizasyonunu ve yapılandırılmasını kolaylaştıran bir metodolojidir. Brad Frost tarafından tasarlanan Atomic Design, kullanıcı arayüzlerini en temel yapı taşlarına ayırdığı ve onları daha karmaşık yapılar halinde yeniden bir araya getirdiği için kimyadan ilham alıyor.

İşte kimyaya benzetmeyi gösteren bir resim:

Kimyasal reaksiyonlar genellikle atomik elementlerin molekül oluşturmak üzere nasıl bir araya geldiğini gösteren kimyasal denklemlerle temsil edilir. Yukarıdaki örnekte hidrojen ve oksijenin bir araya gelerek su moleküllerini nasıl oluşturduğunu görüyoruz.

Özünde atom tasarımı, esnek ve ölçeklenebilir bileşenler oluşturmaya yönelik sistematik bir yaklaşım sağlayan tasarım sistemlerinin doğal bir evrimidir. Bu metodolojinin modüler yapısı, sistem içindeki bileşenlerin ve kalıpların bakımını, güncellenmesini ve genişletilmesini kolaylaştırdığından, atom tasarımı ilkelerini uygulayarak ekipler tasarım sistemlerini daha verimli bir şekilde yönetebilirler.

Bunun karmaşık görünebileceğinden endişeleniyorsanız endişelenmeyin. Gelecek bölümlerde, kendi projelerinizde anlaşılmasını ve uygulanmasını kolaylaştıracak şekilde, geliştirdiğim uygulamadan gerçek hayattan bir örnek kullanarak bu ilkeleri nasıl uygulayacağınızı göstereceğim.

Atom tasarımına genel bakış

Atomik tasarım, bileşenleri her biri bir öncekinin üzerine inşa edilecek şekilde beş farklı seviyede düzenler. Bu beş seviyeyi ayrıntılı olarak inceleyelim:

• atomlar : Bir kullanıcı arayüzünün en temel yapı taşlarıdır; atomlar, düğmeler, giriş alanları ve başlıklar gibi ayrı HTML öğelerini temsil eder. Bunlar en küçük fonksiyonel birimlerdir ve daha fazla parçalanamazlar.

  
  

• Moleküller : Moleküller, iki veya daha fazla atomun fonksiyonel bir grup halinde birleştirilmesiyle oluşur. Örneğin, bir arama formu molekülü, bir arama girdi atomu, bir düğme atomu ve bir etiket atomundan oluşabilir. Moleküller bir projede yeniden kullanılabilecek basit bileşenleri temsil eder.

  
  

• organizmalar : organizmalar, birden fazla molekül ve/veya atomun birleştirilmesiyle oluşturulan daha karmaşık bileşenlerdir. Üst bilgi, alt bilgi veya kenar çubuğu gibi kullanıcı arayüzünün farklı bölümlerini temsil ederler. Organizmalar bir sayfanın genel düzenini ve yapısını oluşturmaya yardımcı olur.

  
  

• şablonlar : şablonlar esasen organizmalar, moleküller ve atomlar kullanılarak oluşturulan sayfa düzenleridir. Herhangi bir gerçek içeriği belirtmeden bir sayfadaki bileşenlerin yapısını ve düzenini tanımlarlar ve çeşitli içerik senaryoları için bir plan görevi görürler.

  
  

• sayfalar : sayfalar, gerçek içerik ve verilerle tamamlanan, şablonların tamamen gerçekleştirilmiş nihai örnekleridir. Bileşenlerin ve düzenin farklı içerik türlerine ve kullanım senaryolarına nasıl uyum sağladığını göstererek, kullanıcıların nihai olarak neyi göreceğini ve etkileşimde bulunacağını temsil eder.

  
  

NotionLingo uygulaması: bir vaka çalışması

Ön uç geliştirme için atom tasarımına ilişkin bilgili bir bakış açısı geliştirmek amacıyla bir uygulama oluşturma yolculuğuna çıktım. Altı aylık bir süre boyunca bu proje üzerinde çalışırken değerli bilgiler ve deneyimler kazandım.

Sonuç olarak, bu makale boyunca verilen örnekler uygulamayla ilgili uygulamalı deneyimimden alınmıştır. Şeffaflığı korumak için tüm örnekler kamuya açık kodlardan alınmıştır.

Depoyu veya web sitesini ziyaret ederek nihai sonucu keşfedebilirsiniz.

Unutmayın, React'ta kodlanmış örnekleri kullanacağım. Bu dile aşina değilseniz endişelenmeyin; kodun en ince ayrıntılarına odaklanmak yerine atom tasarımının temel kavramlarını göstermeyi amaçladım.

Atomlar

Depomdaki bileşenleri daha iyi anlamak için bunları şu dizinde bulabilirsiniz: /client/presentation . Bu konumda atom tasarımı metodolojisiyle tutarlı adlandırma sağlamak için atoms adında yeni bir dizin oluşturdum. Bu yeni dizin, tüm katılım sürecini oluşturmak için gereken tüm küçük parçaları içerir.

Atomların tam listesi aşağıdaki gibidir:

 atoms ├── box ├── button ├── card ├── card-body ├── card-footer ├── container ├── divider ├── flex ├── form-control ├── form-error-message ├── form-helper-text ├── form-label ├── heading ├── icon ├── input ├── list ├── list-icon ├── list-item ├── spinner ├── tab ├── tab-list ├── tab-panel ├── tab-panels ├── tabs └── text

Bu atom adları Chakra UI paketini temel aldığından size tanıdık gelebilir. Birçoğu zaten uygulamam için varsayılan eşleme stilini içeriyor, dolayısıyla bu düzeyde tanımlanacak özellikle benzersiz bir şey yok. Bunu aklımızda tutarak, doğrudan molecules tartışmaya devam edebiliriz.

Moleküller

Bu aşamada atom tasarımı süreci daha ilgi çekici hale gelir ve gerçek gücü kendini ortaya çıkarmaya başlar. Baz atomlarınızı tanımlamak zaman alıcı ve monoton bir iş olsa da, atomları kullanarak yeni bileşenler oluşturmak çok daha keyifli hale geliyor.

Molekülleri tanımlamak için /client/presentation dizinimin içinde bir molecules dizini oluşturdum. Gerekli moleküllerin tam listesi aşağıdaki gibidir:

 molecules ├── available-notion-database ├── full-screen-loader ├── input-control ├── onboarding-step-layout └── onboarding-tab-list

Aslında sadece beş molekülle hedefimize ulaşmaya yetecek kadar bileşene sahibiz. Buranın aynı zamanda diğer atomlar üzerine inşa edilen ortak düzenleri dahil etmek için de ideal bir yer olduğunu unutmamak önemlidir. Örneğin, onboarding-step-layout katılım sürecinin beş adımının tümü boyunca tutarlı bir görünüm sağlamak için kullanılır.

Diğer bileşenler aşağıdaki gibidir:

• Available-notion-database : Getirilen kullanıcının veritabanı ayrıntılarını görüntülemek için kullanılır (kullanıcıların birden fazla veritabanı olabilir, bu nedenle 4. adımda birini seçme olanağı sunuyorum).

  
  

  Bileşen kullanıcı arayüzünde şu şekilde görünür:

• tam ekran yükleyici : Kullanıcının Notion entegrasyonunu önceden tanımlayıp tanımlamadığını kontrol etmek için kullanıcı ayrıntılarını alırken en başta kullanılır. Bu bileşenin kodu şöyle görünür:

 import { FC } from 'react'; import { Flex, Spinner } from '@presentation/atoms'; import { FullScreenLoaderProps } from './full-screen-loader.types'; export const FullScreenLoader: FC<FullScreenLoaderProps> = ({ children, ...restProps }): JSX.Element => ( <Flex alignItems="center" bg="gray.50" height="full" justifyContent="center" left={0} position="fixed" top={0} width="full" zIndex="9999" {...restProps} > <Spinner /> {children} </Flex> );

Burada roket bilimi yok. Bu sadece önceden tanımlanmış flex ve spinner atomların bir birleşimidir.

• input-control : input atomu için form-label , form-control , form-error-label ve spinner içeren, arka planda bir eylem olup olmadığını gösteren bir sarmalayıcı. Bileşen kullanıcı arayüzünde şu şekilde görünür:

• onboarding-tab-list : Bu temelde bir adım bileşenidir, ancak benim durumumda gezinme için Chakra UI sekmelerini kullanıyorum, yani adın geldiği yer burasıdır. Bileşen şu şekilde görünür:

Artık daha fazla parça hazır olduğuna göre tasarım bulmacamızda daha büyük bloklar tanımlamaya geçebiliriz.

Organizmalar

Bu bölüm, katılım sürecinin her adımını görüntülemekten sorumlu her bileşeni oluşturduğum yerdir.

Konuyu açıklığa kavuşturmak için size yaratılmış organizmaların listesini göstereceğim:

 organisms ├── onboarding-step-one ├── onboarding-step-two ├── onboarding-step-three ├── onboarding-step-four └── onboarding-step-five

İsimlerin kendini açıklayıcı olduğuna ve hiçbir yanlış anlaşılma olmaması gerektiğine inanıyorum. Her şeyi nasıl bir araya getirdiğimi göstermek için örnek olarak tek adımın kodunu sunacağım. Elbette daha fazlasını kontrol etmek istiyorsanız depomu ziyaret etmeniz yeterli.

 export const OnboardingStepFour: FC<OnboardingStepFourProps> = ({ onBackButtonClick, onNextButtonClick, }): JSX.Element => { const { hasApiTokenData, isSetApiTokenLoading, setApiToken, setApiTokenError } = useSetApiToken(); const handleInputChange = debounce(async (event: ChangeEvent<HTMLInputElement>) => { const result = await setApiToken(event.target.value); if (result) { onNextButtonClick(); } }, 1000); return ( <OnboardingStepLayout subtitle="Paste your copied integration token below to validate your integration." title="Validate your integration" onBackButtonClick={onBackButtonClick} > <InputControl isRequired errorMessage={setApiTokenError || undefined} isDisabled={isSetApiTokenLoading || hasApiTokenData} isLoading={isSetApiTokenLoading} label="Integration token" name="integrationToken" placeholder="Your integration token" onChange={handleInputChange} /> </OnboardingStepLayout> ); };

Bu kod, katılım sürecimde dördüncü adımın görüntülenmesinden tamamen sorumludur. Sahip olabileceğiniz tek endişenin organizmalarda istekte bulunmak olduğuna inanıyorum. Bu kabul edilebilir mi? Herkese uygun tek bir cevap yok ve bu endişelere "Duruma göre değişir" şeklinde yanıt vermem gerekiyor. Bu sizin yapınıza bağlıdır.

Bir molekül veya organizmaya bir API çağrısı eklemek, uygulamanız bağlamında anlamlıysa ve bileşeni aşırı derecede karmaşıklaştırmıyorsa, kabul edilebilir bir çözüm olabilir. Sunum bileşenlerinin veri toplama veya iş mantığıyla çok sıkı bir şekilde bağlantılı olmasına izin vermemeye dikkat edin; çünkü bu, bunların bakımını ve test edilmesini daha zor hale getirebilir.

Benim senaryomda bu bileşen tek bir yerde kullanılıyor ve bu senaryoda API çağrısı gerçekleştirmek için kullanılan diğer çözümler daha karmaşıktır ve gereğinden fazla kod üretebilir.

Şablonlar

Bu aşamada, kullanıcı arayüzünün ince ayrıntıları yerine bileşenlerin yapısı ve düzenine odaklanılır. Şablonlar ayrıca, genellikle şablonları kullanan sayfa bileşenlerinde bulunan durum yönetiminin nerede bulunması gerektiğini belirlemeye de yardımcı olur.

Sağlanan kod örneğinde şablon görevi gören bir Onboarding bileşenimiz var:

 import { FC } from 'react'; import { Flex, Heading, TabPanels, Tabs, Text } from '@presentation/atoms'; import { OnboardingTabList } from '@presentation/molecules'; import { OnboardingStepFive, OnboardingStepFour, OnboardingStepOne, OnboardingStepThree, OnboardingStepTwo, } from '@presentation/organisms'; import { OnboardingProps } from './onboarding.types'; export const Onboarding: FC<OnboardingProps> = ({ activeTabs, createNotionIntegrationTabRef, displayCreateNotionIntegrationTab, displaySelectNotionDatabaseTab, displayShareDatabaseIntegrationTab, displayValidateIntegrationTab, displayVerifyDatabaseTab, selectNotionDatabaseTabRef, shareDatabaseIntegrationTabRef, validateIntegrationTabRef, verifyDatabaseTabRef, }) => ( <Flex direction="column" overflowX="hidden" px={2} py={{ base: '20px', sm: '25px', md: '55px' }}> <Flex direction="column" textAlign="center"> <Heading color="gray.700" fontSize={{ base: 'xl', sm: '2xl', md: '3xl', lg: '4xl' }} fontWeight="bold" mb="8px" > Configure your Notion integration </Heading> <Text withBalancer color="gray.400" fontWeight="normal"> This information will let us know from which Notion database we should use to get your vocabulary. </Text> </Flex> <Tabs isLazy display="flex" flexDirection="column" mt={{ base: '10px', sm: '25px', md: '35px' }} variant="unstyled" > <OnboardingTabList activeTabs={activeTabs} createNotionIntegrationTabRef={createNotionIntegrationTabRef} selectNotionDatabaseTabRef={selectNotionDatabaseTabRef} shareDatabaseIntegrationTabRef={shareDatabaseIntegrationTabRef} validateIntegrationTabRef={validateIntegrationTabRef} verifyDatabaseTabRef={verifyDatabaseTabRef} /> <TabPanels maxW={{ md: '90%', lg: '100%' }} mt={{ base: '10px', md: '24px' }} mx="auto"> <OnboardingStepOne onNextButtonClick={displayCreateNotionIntegrationTab} /> <OnboardingStepTwo onBackButtonClick={displayVerifyDatabaseTab} onNextButtonClick={displayShareDatabaseIntegrationTab} /> <OnboardingStepThree onBackButtonClick={displayCreateNotionIntegrationTab} onNextButtonClick={displayValidateIntegrationTab} /> {activeTabs.validateIntegration ? ( <OnboardingStepFour onBackButtonClick={displayShareDatabaseIntegrationTab} onNextButtonClick={displaySelectNotionDatabaseTab} /> ) : null} {activeTabs.selectNotionDatabase ? ( <OnboardingStepFive onBackButtonClick={displayVerifyDatabaseTab} /> ) : null} </TabPanels> </Tabs> </Flex> );

Bu Onboarding bileşeni, katılım sürecinin düzenini oluşturmak için atomları, molekülleri ve organizmaları bir araya getirir. Durum yönetimi ve sekme gezinme mantığının bu bileşenden ayrıldığına dikkat edin. Gerekli durum ve geri çağırma işlevleri artık destek olarak alınmakta ve daha üst düzey bir "sayfa" bileşeninin durum ve veri yönetimini yönetmesine olanak sağlanmaktadır.

Bu endişelerin ayrılması, şablonun düzen ve yapıya odaklanmasını sağlarken durum yönetiminin uygun düzeyde ele alınmasını sağlar.

Sonunda, nihai sonuç olarak 4. adımı sunmak istiyorum:

Sayfalar

Önceki tartışmamız bağlamında, "sayfa" bileşeni Onboarding şablonunu kullanır ve katılım süreci için durum yönetimini yönetir. Bu spesifik sayfa bileşeninin kodu burada verilmese de, onu depomda bulabilirsiniz. Belirtildiği gibi sayfa bileşeninin kodunda olağanüstü bir şey yok; öncelikle durumu yönetmeye ve onu Onboarding şablonuna aktarmaya odaklanır.

Atom tasarımının pratikte nasıl göründüğüne bir bakalım. Bu yaklaşımın artılarını ve eksilerini inceleyelim.

Dikensiz gül olmaz

Atom tasarımı modülerlik, yeniden kullanılabilirlik ve sürdürülebilirlik gibi çok sayıda belirgin fayda sunarken, aynı zamanda başlangıçta dikkate alınması gereken birkaç dezavantajı da beraberinde getiriyor:

• İlk kurulum ve karmaşıklık : Atom tasarımı, iyi planlanmış bir yapı ve organizasyon gerektirir; bu, başlangıçta kurulumu zaman alıcı ve zorlayıcı olabilir. Ayrıca, özellikle bu tür ayrıntılı bir yaklaşımın gereksiz olabileceği küçük projeler için kod tabanınıza ek karmaşıklık da getirebilir.

  
  

• Öğrenme eğrisi : Atomik tasarıma yeni başlayan geliştiriciler için metodolojinin öğrenme eğrisi dik olabilir. Farklı seviyelerin ve bunların birbirine nasıl uyum sağladığının sağlam bir şekilde anlaşılmasını gerektirir ki bu, yeni başlayanlar için çok zor olabilir.

  
  

• genel gider : atom tasarımının uygulanması, çok sayıda küçük, özel bileşenin oluşturulmasını gerektirebilir. Bu, özellikle bir bileşen yalnızca belirli bir bağlamda kullanıldığında, bu bileşenlerin yönetimi ve bakımında artan ek yüke yol açabilir.

  
  

• Aşırı mühendislik riski : Yeniden kullanılabilir ve modüler bileşenler oluşturmaya odaklanıldığında, geliştiricilerin daha geniş uygulamaya odaklanmak yerine tek tek bileşenleri geliştirmek için çok fazla zaman harcayabileceği potansiyel bir aşırı mühendislik riski vardır.

  
  

• İletişim ve işbirliği : Atom tasarımının başarısı, tasarımcılar, geliştiriciler ve diğer paydaşlar arasındaki açık iletişime ve işbirliğine bağlıdır. Ortak bir dil veya metodoloji anlayışının oluşturulamaması, uygulamada kafa karışıklığına ve tutarsızlıklara yol açabilir.

Ancak bu yaklaşımın daha önce bahsedilen kendi güçlü yönleri vardır. Onlar hakkında daha ayrıntılı olarak konuşalım:

• ölçeklenebilirlik : Tasarımı en temel öğelere ayırarak bileşenlerin karmaşıklığını artırmak daha yönetilebilir bir görev haline geldi. Atomları işlemek bazı zorluklara yol açsa da, bu atomları temel alan herhangi bir bileşeni oluşturmak son derece keyifliydi.

  
  

• verimlilik : atomları, molekülleri ve organizmaları yeniden kullanma yeteneği, yeni özelliklerin tasarlanması ve geliştirilmesi için harcanan zamanı önemli ölçüde azaltır. Temel bileşenler oluşturulduktan sonra yeni arayüzler oluşturmak, mevcut öğeleri birleştirmek kadar basit olabilir.

  
  

• tutarlılık : doğrudan bir önceki noktadan gelir. Birden fazla şablon ve sayfada aynı atomlar, moleküller ve organizmalar kullanıldığından, kullanıcı arayüzü tekdüze kalarak kullanıcılara kusursuz bir deneyim sunar.

  
  

• dokümantasyon : atom tasarımı doğası gereği dokümantasyonu destekler. Atom tabanlı yapı, bileşenlerin nasıl oluşturulup kullanılması gerektiği konusunda net, görsel bir kılavuz görevi görebilir. Bu, özellikle yeni ekip üyelerinin işe alınmasında yararlı olabilir.

  
  

• Sürdürülebilirlik : Atom tasarımının en güçlü yönlerinden biri, bir tasarım sisteminin sürdürülebilirliğine nasıl katkıda bulunduğudur. Her şeyi atomik parçalarına ayırarak, atomik seviyede herhangi bir değişiklik veya güncelleme yapılabilir ve daha sonra sisteme yayılabilir. Örneğin, bir düğmenin rengini değiştirmeye karar verirseniz, bu değişikliği atom düzeyinde yalnızca bir kez yapmanız yeterlidir ve bu, bu düğmenin kullanıldığı tüm moleküllere, organizmalara ve şablonlara yansıyacaktır. Bu, tasarım sisteminin zaman içinde güncellenmesi ve sürdürülmesi sürecini büyük ölçüde basitleştirir.

Çözüm

Sonuç olarak, atom tasarımı iki ucu keskin bir kılıç gibi görünse de (ilk kurulum ve öğrenme eğrisi açısından biraz göz korkutucu), potansiyel faydaları ilk baştaki mücadeleye değer. Ve unutmayın, en zorlu kılıçlar bile yetenekli bir şövalyenin elinde zararsızdır!