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. üzerinde çalışırken temiz mimari yaklaşımını ön uç uygulamalarda uygulama deneyimimi paylaşmıştım. Bir önceki yazımda yan projem 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. 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. Tasarım sistemleri, 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 göz atmanızı öneririm. Bu konuyu ayrıntılı olarak, bu çalışma kapsamında bizim için gerekli olmayan detayları anlatmaktadır. bu makaleye 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. 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. Brad Frost tarafından tasarlanan Atomic Design, İş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: : 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. atomlar : 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. Moleküller : 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. organizmalar : ş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. şablonlar : 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. sayfalar 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. veya ziyaret ederek nihai sonucu keşfedebilirsiniz. Depoyu web sitesini Unutmayın, 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. React'ta Atomlar Depomdaki bileşenleri daha iyi anlamak için bunları şu dizinde bulabilirsiniz: . Bu konumda atom tasarımı metodolojisiyle tutarlı adlandırma sağlamak için 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. /client/presentation atoms 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ı 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 tartışmaya devam edebiliriz. Chakra UI molecules 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 dizinimin içinde bir dizini oluşturdum. Gerekli moleküllerin tam listesi aşağıdaki gibidir: /client/presentation molecules 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, 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. onboarding-step-layout Diğer bileşenler aşağıdaki gibidir: : 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). Available-notion-database Bileşen kullanıcı arayüzünde şu şekilde görünür: : 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: tam ekran yükleyici 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ış ve atomların bir birleşimidir. flex spinner : atomu için , , ve 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: input-control input form-label form-control form-error-label spinner : Bu temelde bir adım bileşenidir, ancak benim durumumda gezinme için sekmelerini kullanıyorum, yani adın geldiği yer burasıdır. Bileşen şu şekilde görünür: onboarding-tab-list Chakra UI 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 ziyaret etmeniz yeterli. depomu 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 bileşenimiz var: Onboarding 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 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. Onboarding 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 ş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 şablonuna aktarmaya odaklanır. Onboarding Onboarding 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: : 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. İlk kurulum ve karmaşıklık : 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. Öğrenme eğrisi : 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. genel gider : 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. Aşırı mühendislik riski : 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. İletişim ve işbirliği 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: : 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. ölçeklenebilirlik : 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. verimlilik : 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. tutarlılık : 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. dokümantasyon : 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. Sürdürülebilirlik Çö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!
