React, ön uç geliştirme boşluğunda nasıl bir köprü haline geliyor?

Bazıları front-end tasarımın bir sanatçı olduğunu söylerken, diğerleri front-end tasarımın web sayfası geliştirme ile ilgili olduğunu söylüyor. Diğerleri front-end tasarımın upstream etkileşim tasarımcıları ve downstream sunucu tarafı mühendisleri arasında bir köprü olduğunu söylüyor ... Sonra Teknik açıdan bakıldığında, ön uç tasarımı tam olarak nedir? Günümüzün ana akım JavaScript çerçevesi olarak, React ön uç geliştirmede hangi rolü oynuyor?

Yazar | Brad Frost

Çevirmen | Su Benru, sorumlu editör | Tu Min

Üretildi | CSDN ( İD: CSDNhaberler)

Aşağıdaki çeviridir:

Ön uç tasarımcının ana sorumluluğu, kullanıcı arayüzünü görüntülemek için kullanılan HTML, CSS ve JavaScript kodunu oluşturmaktır. Benim bakış açıma göre, ön uç tasarımı, web sitesi tasarımı ile arka uç geliştirme arasındaki boşluğu doldurabilecek yararlı bir yapıştırıcıdır.

Venn şeması, bir uç tasarımı gösterir, bir uç gelişimi gösterir ve orta ön uç tasarımı ikisini birbirine bağlar

Tabii ki, "ön uç tasarımcıları" onlar için doğru isim olabilir veya olmayabilir. Aşağıdaki isimler bazı şirketler tarafından kullanılabilir:

  • UI geliştiricisi

  • Müşteri Geliştirici

  • Kullanıcı arayüzü mühendisi

  • tasarım mühendisi

  • Ön uç mimar

  • Tasarımcı / Geliştirici

  • Prototip geliştirici

  • Yaratıcı teknoloji uzmanı

  • Diğer (Bil bakalım ne oldu)

Bununla birlikte, onlara hangi etiket yapıştırılmış olursa olsun, sorumlulukları web sitesi kullanıcı arayüzü için kod yazmaya odaklanmaktır. Aşağıdakiler, ön uç tasarımcıların günlük çalışmalarıdır:

  • Ayrıntılı HTML anlamsal etiketleri , Odaklan Dikkat Tarayıcılar için erişilebilirlik, yardımcı teknoloji, aramak HTML kullanabilen motorlar ve diğer ortamlar arkadaşça bir deneyim sağlar.

  • Web deneyiminin görünümünü ve hissini kontrol eden CSS kodu oluşturun , Renk, tipografi, duyarlı düzen, animasyon ve kullanıcı arayüzünün diğer görsel yönlerini işlemek için. Ön uç tasarımcılar esnek CSS kodu oluşturur, odaklanır Dikkat Modülerlik, esneklik, uyumluluk ve ölçeklenebilirlik.

  • Genelde DOM'daki nesneleri işleyen Javascript kodu yazın Akordeon panelinin başlığına tıklandığında akordeon panelinin açılması veya kapatılması veya gezinme panelinin kapatılması gibi.

  • Tarayıcılar ve cihazlar arasında test edin , Kullanıcı arayüzünün sonsuz masaüstü bilgisayarlarda, cep telefonlarında, tabletlerde ve web sayfalarını destekleyen diğer cihazlarda (henüz icat edilmemiş cihazlarda bile) pratik ve güzel olmasını sağlamak.

  • Ön uç kodun performansını optimize edin Hafif, hızlı yükleme, özlü ve sorunsuz bir deneyim sağlamak için.

  • Tasarımcılarla işbirliği yapın , Markanın, tasarım vizyonunun ve kullanıcı deneyiminin en iyi uygulamalarının tarayıcıda doğru bir şekilde görüntülenmesini sağlamak için, tarayıcının gerçek kullanıcıların gerçek ürünü kullandığı gerçek konum olduğunu size hatırlatın.

Ön ucun arka uç kodu, hizmetler, API'ler ve diğer teknik mimarilerle uyumlu olmasını sağlamak için arka uç geliştiricilerle ve uygulama geliştiricileriyle birlikte çalışın.

Yukarıdaki içeriği okuduktan sonra, "Pekala, Brad, bunlar yeni bir şey değil" diyebilirsiniz. Ancak, bu ön uç geliştiricilerin sorumluluklarını listeledim: ön uç geliştirme zor ve incelikli bir iştir Çok fazla düşünme, özen ve özen gerektirir. Dikkat . Ön uç tasarım tam zamanlı bir iştir ve ciddiye alınmalıdır.

Ayrıca yukarıdakileri okuyup "Ön uç geliştiricilerin yaptığı tam olarak bunlar değil mi?" Diye düşünüyor olabilirsiniz. Cevap ... Belki. Kesinlikle harika bir makale olarak, " "Büyük Bölünme" bu noktayı detaylandırdı (cidden, okumadıysanız, lütfen kendinize bir iyilik yapın ve şimdi okuyun): Javascript büyümeden, mevcut "ön uç geliştirme" İş yükü inanılmaz derecede arttı.

"Ön uç geliştirme" nin iş yükü o kadar büyük ki, şaka yollu bir şekilde bir ön uç tasarımcısı olarak "ön uç ön uçta" yaşarken diğer birçok geliştirici "ön uç arka uçta" yaşadığımı söyleyebilirim. Burada istiyorum Dikkat İşte fark, çünkü React gibi JavaScript çerçevelerinde bu büyük boşluk çok gerçek bir şekilde ortaya çıkıyor.

Ön uç tasarımcısı React dünyasında kayboldu

React web sitesinden gelen karşılama mesajı: "kullanıcı arayüzleri oluşturmak için bir Javascript kütüphanesi" dir.

Kullanıcı arayüzünü oluşturun! Aslında, ben de tam olarak bunu yapıyorum On yıldan fazla bir süredir profesyonel olarak kullanıcı arayüzleri oluşturuyorum. Bu benim zevkime uyuyor.

Ancak durum böyle değil veya en azından bir front-end tasarımcı olarak çalışmam için bariz bir fayda değil.

"UI Mühendisliğinin Öğeleri" adlı makalesinde Dan Abramov, büyük ölçekli uygulamalar için kullanıcı arayüzleri oluştururken karşılaştığı birçok zorluğu açıklıyor. Benim için, bu makale "ön uç ve arka uç" ile "ön uç ve ön uç" arasındaki farkı mükemmel bir şekilde gösteriyor. Bu yazıda bahsettiği her şey kulağa çok önemli geliyor ama çoğunun bana yabancı dil olarak göründüğü inkar edilemez. Verileri senkronize tutmak, önbellek geçersiz kılmak, yönetim durumu, yönlendirme nüanslarını ele almak ve diğer bazı hususları neyse ki işimin bir parçası olmadı. Bunu yapmayı tercih ederim.

React gibi JS çerçevelerinin yükselişi tesadüfi değildir. Bu çerçeveler, büyük ölçekli uygulamalar oluştururken geliştiricilerin gerçek ihtiyaçlarına çözümler sağlar. Bu çerçevelerin bu uygulama geliştiricilere bu görevleri tamamlamalarına yardımcı olabileceği için çok mutluyum.

Ancak, bu çözümleri oluşturmak bir yan ürün de getirdi, işte bu HTML ve CSS yemek sorunudur. Çünkü ön uç Web tarafından geliştirilen HTML ve CSS'yi yer ve onu büyük bir Javascript topuna dönüştürür. Bu, ön uç tasarımcılar için ciddi bir engel oluşturur.

React'i öğrenme çabalarımı paylaştım ve bir grup insandan büyük bir coşku hissettim. Ama aynı zamanda bunalmış bir grup insandan (genellikle özel) pek çok mektup aldım ve almaya devam ediyorum. Bana inanmıyorsanız, harika Jonathan Snook'un (uzun vadeli kahramanlarımdan biri, benden daha uzun süredir ön uç geliştirme yapıyor) yazdığı son makaleye göz atabilirsiniz ve o makalede paylaştı. Kendi kişisel React öğrenme deneyiminden öğrenmek için:

Kıdemli bir geliştirici olduğumu hayal etmek zor, genç bir geliştirici gibi hissediyorum. Genellikle bir şeyleri anlamak için gerekenden çok daha fazla zaman harcıyorum ve bu süreçte hayal kırıklığına uğradım. Anlamadığım bir şeyi açıklayacak birini bulmadan önce, günde iki hatta üç gün herhangi bir ilerleme kaydedemeyebilirim. Yeterince iyi olmadığımı hissediyorum ama bunu yapmam gerektiğini hissediyorum.

Görünüşe göre ön uç tasarımcıları React'te sıkışıp kalıyor, bu yüzden burada keşfetmeye değer bir şeyler olması gerektiğini düşünüyorum.

Bileşen hodgepodge

React'te her şey bir bileşendir. Bir kişinin ekranda gerçekten gördüğü düğme bir bileşendir. Düğmeye tıklandığında ne olacağını idare eden iş mantığı bir bileşendir. Bir uygulamaya tıkladığınızda, sizi götürdüğü rota bir bileşendir. Baştan sona tüm gördüğünüz bileşenlerdir.

Bunların hiçbiri yanlış değil, ancak insanları smorgasbord bileşen içeren bir uygulama gördüklerinde bunalmış hissettikleri için suçlayamam. Bu bileşenler çeşitli şeylerden sorumludur ve hepsini paketinden çıkarmaları gerekir. Jonathan şöyle dedi:

Diğer her şeyi aynı anda atın, kolay olmasına rağmen, ancak işler karışacak, çünkü neyin neye ait olduğunu ilk başta belirlemek zor. "Oh, bu Redux. Bu React. Diğeri Lodash. Tamam, anlıyorum."

Sadece React çerçevesiyle değil, React çerçevesi ve yardımcı çerçeveleriyle de ilgileniyoruz.

Şimdi birden fazla React kod tabanında çalıştım.Bence bunlar iş mantığı, ekran kodu, veri işleme kodu ve opak bir dosya yapısına sarılmış diğer görünüşte korkutucu kod biçimleridir. Hibrit. Başka bir açıdan bakarsanız, orada bir yere dağılmış bazı HTML'ler bulabilirsiniz. Hiç şüphe yok ki bu uygulamadan kaynaklanıyor, ancak yine de insanları çıldırtabilir.

Dan Abramov'un makalesinde bir umut ışığı görene kadar kendimi çok sinirli hissettiğimi itiraf ediyorum. Dan, sunum (aptal) bileşenleri ile kapsayıcı (akıllı) bileşenler arasındaki farktan bahsetti. Bu, ilk kez bu çılgın JS dünyasında bana ait bir yer olabileceğini hissettirdi.

Bir buçuk yıldır React tabanlı müşteri projeleri üzerinde çalışıyorum ve şimdi size bu front-end tasarımcının bu yeni JS dünyasında bir yol açtığını söylemekten mutluluk duyabilirim.

Ön uç tasarımcıların bu yeni JavaScript dünyasındaki konumu

Kalıp kitaplığı çılgınlığının yükselişiyle birlikte Dave Rupert, her müşteri için "küçük bir yükleyici" sunmamız gerektiğini söyledi ve şunları söyledi:

Duyarlı çıktılar, müşterilerin ihtiyaçlarına göre uyarlanabilen, tamamen işlevsel bir Twitter rehberli stil sistemine çok benzemelidir.

İfadesi, özellikle "müşteri ihtiyaçlarına göre uyarlanmış" bölümün kafasına çivi çaktı. Tasarım sistemlerinin patlayıcı gelişiminin bir sonucu olarak gördüğümüz şey budur: tüm bu kalıp kitaplıkları, her kuruluşun zorlu kullanıcı arayüzü sorunlarına çözümler içerir.

Bootstrap'e geri dönersek, geçmişte yaşanan sorun, geliştiricilerin Bootstrap'in CSS ve JS dosyalarını birbirine bağlayabilmesiydi, ancak Bootstrap'in HTML'sini manuel olarak kendi ortamlarına dönüştürmeleri gerekiyordu.

Bu yeni dünyada işlerin çalışma şekli değişti. Artık doğrudan tüketilebilir (kullanılabilir) bileşenlerimiz var, bu da bileşenlerin yapısı, stili ve davranışının kısa ve temiz bir paket olarak birlikte sunulabileceği anlamına geliyor. Bu, işlerin son derece heyecan verici şekillerde çalışma şeklini değiştirdi.

React dünyasında, bu popüler ön uç kullanıcı arabirimi kitaplıklarını doğrudan kullanılabilen (kullanılabilen) React bileşenlerine dönüştürebilen Material UI ve React Bootstrap gibi çerçeveler vardır. Bu önceden hazırlanmış çözümlerin yeri var, ancak birçok kuruluş kendi ihtiyaçlarını karşılamak için kendi özel UI bileşen kitaplıklarını oluşturuyor. Salesforce'un Lightning Design System for React, IBM'in React tarzı Carbon Design System, Shopify'ın Polaris sistemi ve daha birçok örnek sistemi inceleyebilirsiniz.

Bu nedenle, doğrudan tüketilebilir (kullanılabilir) UI bileşenlerini hesaba katarsanız, Dave Rupertın bilgelik sözleriyle ilgili son düşüncelerimi burada bulabilirsiniz:

Ön uç tasarım çıktıları, müşteri ihtiyaçlarına göre uyarlanmış, tamamen işlevsel bir React kılavuzlu sisteme çok benzemelidir.

Bu ince ama önemli bir farktır. Ön uç tasarımcılar yalnızca bileşen referansı HTML, CSS ve görüntü JS kodu oluşturmakla kalmaz, aynı zamanda doğrudan kullanılabilir HTML, CSS ve görüntü JS kodu oluşturabilir, böylece arka uç geliştiriciler ona canlılık katabilir. Ancak "müşteri ihtiyaçlarına göre özel yapım" ın değişmeden kaldığını lütfen unutmayın. Burada "sadece React önyükleyicisini kullanın" dan bahsetmiyorum, özel ihtiyaçlarınızı karşılayan bir UI bileşen kitaplığı oluşturmaktan bahsediyorum.

Gördüğüm gibi, doğrudan tüketilebilir (kullanılabilir) UI bileşenleri, ön uç ile arka uç arasındaki büyük boşluğu kapatmak için bir köprü görevi görebilir ve ön uç geliştirmenin ön ucu ile ön uç geliştirmenin arka ucu arasında sağlıklı bir el sıkışma mekanizması oluşturabilir.

Bu nedenle, bunu başarmak için, bu makalenin başında ön uç geliştiricilerin sorumlulukları listesine aşağıdaki sorumlulukları eklemeliyim:

  • Kullanıcı arabirimi bileşenleri kitaplığının bir vitrinini oluşturun , Diğer geliştiriciler tarafından kullanılmak üzere paketlenmiştir.

  • Her ekran bileşeni için güçlü ve sezgisel bir bileşen API'si yazın ve kaydedin , Böylece bileşeni kullanan geliştiriciler ihtiyaç duydukları her şeyi kolayca ekleyebilir.

  • Bileşen kitaplığının ne kadar esnek veya katı olması gerektiğini belirleyin , Her bir bileşenin açık / bir araya getirilebilir veya sert / kilitli olması gerektiğini anlamak için geliştiricilerle birlikte çalışın.

  • Ekran bileşenini bir ürün olarak koruyun , Bu, sürüm kontrolü, dağıtım, yönetişim, sürüm notları ve yazılım ürünlerinin bakımıyla ilgili tüm işlemlerle ilgilenmem gerektiği anlamına geliyor.

En önemlisi, kollarımı sıvamalı ve React gibi JS frameworklerini öğrenmeliyim. Lütfen tüm React ve yardımcı çerçevelerinin değil, ön uç tasarım çalışmasını yapmak için yalnızca React'in bir kısmının gerekli olduğunu unutmayın.

Sarf malzemesi UI bileşenleri neye benziyor?

Sarf malzemesi kullanıcı arabirimi bileşenleri neye benziyor? Bir Uyarı bileşenine bir göz atalım

Bileşen işaretlemesinin temel noktaları (JSX ile yazılmıştır) aşağıdaki gibidir:

< div className = {`c-alert $ {varyant}`} role = 'alert' {...diğer} > < Simge ad = {iconName} className = 'c-alert__icon' / > < div className = 'c-alert__body' > < h2 className = 'c-alert__title' > {Başlık} < / h2 > < div className = 'c-alert__description' > {çocuklar} < / div >

Uygulama geliştiricilerin dolduracağı dinamik bitlere (başlıklar gibi) yer bırakıyoruz.

Bileşen oluşturulduktan sonra, diğerlerinin onu kullanabilmesi gerekir. Bir yol, uygulamada bir "ui-components" klasörü oluşturmaktır, ancak daha iyi bir yol, onu kendi ürünü olarak yayınlamaktır (bakın! Kendi UI çerçevemi yayınlıyorum!). Bu yolu izlerseniz, ön uç geliştirmenin arka uç geliştiricileri, bileşen kitaplığınızı entegre etmek için aşağıdaki komutları çalıştırabilir:

npm react-design-sistemimizi kurun

Bileşen kitaplığını kurduktan sonra, geliştiriciler Uyarı bileşenini içe aktarabilir:

"react-tasarım-sistemimiz / bileşenlerimiz / Uyarı" ndan uyarı alma; < Uyarmak değişken = "başarı" iconName = "onay kutusu" title = "Profil güncellendi!" > Profilinizi başarıyla güncellediniz. < /Uyarmak >

Uyarı bileşeninin bu kopyası nereden geldi? Bir uyarıyı ne tetikleyecek? Bu, ön uç geliştirmenin arka uç geliştiricilerinin sorumluluğundadır. Bu sunum UI bileşenlerini, iş mantığını, veri işlemlerini ve alarm bileşenini gerçek uygulamada başarılı bir şekilde uygulamak için gereken diğer işlemleri yöneten akıllı bir katmanda paketlediler.

React sarf malzemesi UI bileşenlerini seviyorum

React çerçevesiyle çalışmanın geçen bir buçuk yılında, React ile çalışmakla ilgili en sevdiğim şey React'in kendisine özgü değil, doğrudan tüketilebilir bileşenler kavramı. Son analizde, bu yüzden web bileşenlerini araştırmaktan çok heyecan duyuyorum çünkü bunlar web üzerinde doğdu ve farklı JS çerçeveleriyle birlikte çalışabilirler.

Doğrudan sarf edilebilir kullanıcı arabirimi bileşenleri kavramının önemli noktaları şunlardır:

  • Ön uç kod tabanını merkezileştirir: ön uç uzmanlarının biçimlendirme, stil ve sunum JS kodu için tek bir doğruluk kaynağını yönetmesine olanak tanır. Bu, ön uç kodun spagetti benzeri yayılmasını kontrol etmeye yardımcı olur ve ön uç tasarımcılarının ön uç kodun nasıl tasarlanacağını daha dikkatli bir şekilde değerlendirmesine olanak tanır. UI bileşen kodunu yineleyip iyileştirebilirler ve bu değişiklikleri bileşenin kullanıldığı her yere yayabilirler. Gerçekten çok güçlü!

  • Ön uç tasarımcıları ön uç kodunu kontrol eder: Ön uç olmayan geliştiricilerin, anlamadıkları öznitelikleri atlayarak ihtiyaç duydukları işaretlemeyi kopyalayıp yapıştırdıkları birçok projeye katıldım. Emin olmak için, ARIA özniteliği gizemli bir şekilde ortadan kalkıyor gibi görünüyor, div rastgele olarak ul etiketinin altına yerleştiriliyor ve belge yapısı karmakarışık. Geçmişte, ön uç tasarımcılarının geceleri yastıklarının üzerinde ağlamaktan başka seçeneği yoktu. Bununla birlikte, artık doğrudan tüketilebilir UI bileşenleriyle, ön uç tasarımcılar UI kodunun kontrolünü ellerinde tutabilir ve diğer geliştiricilere, kaynak biçimlendirmesini, stilleri ve görüntü JS'sini ortaya çıkarmak yerine etkileşimde bulunabilecekleri bir API sağlayabilir. Kod.

  • Ön uç en iyi uygulamaları bileşenlere entegre edilebilir: bu çok başarılı ve heyecan verici bir değişikliktir. UI bileşenleri merkezi olarak yönetildiği için, ön uç en iyi uygulamalarını bileşenlere entegre edebilirsiniz ve diğer geliştiriciler bu en iyi uygulamaları ücretsiz olarak edinebilir. Örneğin, daha erişilebilir bir form bileşeni oluşturmak için otomatik olarak oluşturulan bir kimliğin nasıl oluşturulacağını açıklayan bir makale yazdım. Bu bileşenlerle, uygulama geliştiricilerinin artık ezberci ön uç çalışması için endişelenmesine gerek kalmaz, ancak diğer daha değerli görevlere odaklanabilir.

İş akışım

Geçenlerde bu şekilde nasıl çalıştığım hakkında konuştum, bu yüzden iş akışımın ana noktalarını özetleyeyim:

  • Storybook ekibinde bir ön uç geliştirme atölye ortamı olarak çalışın , Temsili ürün sayfaları oluşturarak UI bileşenleri oluşturmama izin veriyor. Çevrimiçi gördüğüm çoğu Storybook versiyonu sadece daha düşük seviyeli bileşenler içeriyor, ancak tüm ürün sayfalarımızı göstermek için Storybook kullanıyoruz. Bu sayfalar, ön uç geliştirmede ekip incelemelerini ve arka uç geliştiricilerin sayfaları arka uç hizmetlerine ve uygulamanın geri kalanına bağlarken bunları referans olarak kullanmalarını kolaylaştıran canlı, canlı bileşenlerdir.

  • Ürün görüntüleme sayfasını oluştururken her bileşen için bir API oluşturdum. olmalı < Düğme metni = "Beni Tıkla" / > , < Düğme etiketi = "Beni Tıkla" / > , hala < Buton > Beni tıkla < /Buton > ? Sezgisel ve tutarlı bir bileşen API'si yazmanın gerçekten sevdiğim bir şey olduğu ortaya çıktı.

  • Sayfalarımızı ve bileşenlerimizi paydaşlarımızla inceledik ve herkes memnun olduğunda, bileşen kitaplığının yeni bileşenleri, varyantları ve düzeltmeleri içeren yeni bir sürümünü başlattık.

  • Ardından, uygulama geliştiricileri en son ve en büyük değişiklikleri ekleyebilir indir Yeni özellikler ve güncellemeler almak için uygulamasına.

Bu iş akışında pek çok ayrıntı var, bu yüzden burada ayrıntıya girmeyeceğim; Gelecekte tanıtmak için bir makale yazabilirim.

React kullanımında acil sorunlar

Bir ön uç tasarımcısı olarak, nihayet bu yeni JS dünyalarında koşmanın bir yolunu bulduğum için gerçekten mutluyum. Birçok kişi benimle iletişime geçti ve React öğrenme yolculuğumun en son durumunu güncellememi istedi Bu makale bir güncellemedir. React ile ilgili sevdiğim pek çok şey olsa da (özellikle yukarıda vurguladığım sarf edilebilir UI bileşenleri), hala çözmem gereken bazı problemler var:

  • Hala JSX yazmayı sevmiyorum. Şimdi kesinlikle daha akıcı yazacak olsam da nedenini bilmiyorum, yine de biraz garip buluyorum. Bazı detayları paylaşabilirim ama bu sadece bazı kızgın, eleştirel yorumlara neden olacaktır. Söylemek istediğim, HTML veya HTML gibi bir şeye (Vue gibi) yazabileceğim bir projeye geçtiğimde, temiz bir nefes gibi hissettiriyor.

  • React ve yardımcı çerçeve: Evan Yu'nun bu konuşmasını, React kitaplığının kendisinin nasıl kasıtlı olarak hafif ayak izli olacak şekilde tasarlandığını açıklamaya yardımcı olması için buldum, bu da bir uygulamanın çalışması için başka kitaplıklara ihtiyaç olduğu anlamına geliyor. Bu hafif ayak izi tasarımı, React çevresinde büyük bir ekosistemin kurulmasına yol açtı ve bu şüphesiz büyük başarısına katkıda bulundu. Ancak yukarıda bahsettiğim gibi, bu bizi her kitaplığın bağlantı noktasını doğru bir şekilde bulmamıza götürür ve bu inanılmaz derecede hızlı hareket eden React ve yardımcı çerçevesinin geliştirme hızına ayak uydurmanızı gerektirir. Ben bir falcı değilim, ancak bir çok takımın önümüzdeki birkaç yıl içinde önceki "yeni etkin nokta" sorunlarını çözmek için çok zaman harcayacağına dair bir önsezim var.

  • Topluluktan güçlü görüşler: Bir React savunucusu ile ekibimizin, müşterilerin panelin açık / kapalı durumunu yönetmek için Redux'u kullanabilmeleri için katlanır bileşenlerimizi nasıl yeniden düzenlediğini tartışıyorum. Bu cümleyi bitirmeden önce, küçümseyici bir şekilde yanıtladı: "Unut gitsin, artık kimse Redux kullanmıyor!" Evet, müşterimin Redux'u nasıl kullandığına dair gerçekten bir hikaye anlatırken , React topluluğundan, kaotik bir gözden kaçırma hissi veren birçok güçlü fikir gördüm. Birlikte çalıştığım her ekip, etrafındakilere ne kadar ayak uydurmaya çalıştıklarını söylüyor.

  • Aşırı dindar olmayın hassas : React ile hiçbir ilgisi olmasa bile bir şeyi ne zaman yorumlasam veya eleştirsem, birinin atlayıp acele edeceğini düşünüyorum. Ben büyüğüm Bağırıyor. Görünüşe göre bazı insanlar React'i ustam ve kurtarıcım olarak kabul etmediğim için çok kızgınlar React ile ilgili herhangi bir soru, eleştiri veya yorum küfürdür. Bu ilginç bir fenomendir. Tabii ki, insanlar React'i çok seviyor ama son tahlilde bu bir araç. Evet, kullandığımız araçların ve teknolojilerin arkasında insanlar var, bu yüzden kavramları ve teknolojileri onları yaratan ve kullananlardan ayırmaya dikkat etmemiz gerekiyor.

  • Araçlar ve inşa adımları gibi şeyler her zaman başımı ağrıtır: Araçlar, ortam ayarları ve inşa adımları, bazılarının gerçekten sevdiği, bazılarının sevmediği şeyler gibi görünüyor. Kişisel olarak bu şeyleri sevmiyorum ve diğer geliştiricilere teslim etmekten mutluluk duyuyorum. React kurulumunun demo versiyonundan çok memnunum (Storybook ve tamamen boş bir Create React uygulaması), ancak ne zaman uygulama kodunu kullanma riskini almam gerektiğinde, bir kıyamet duygusu hissediyorum. .

  • Gerçek trendleri ve güncel özellikleri bulmaya çalışın: Birkaç Github projesini listeleyen "modern ön uç tasarım sistemi yığını" nı tanıtan bir tweet gördüm. Bir yığına atıfta bulunurken, "A" yerine "A" kullandığımıza dikkat edin. ". Bu gerçekten moda. Onu" 2019 sonbaharında bir ürün broşürü satın alın "olarak okudum. Ancak tüm bu gürültüde gerçek eğilimler çalışma şeklimizi etkileyecek. Kendime sormak için çok zaman harcadım. İşimi tamamlamak için bunu önemsemem gerekiyor mu? "" kanca mı? Evet. yönlendirme? Türü. Durum Yönetimi. Türü. veri depolama? Muhtemelen değil. Elbette, birinin bunları önemsemesi gerekiyor ve onlarla yakın çalışmayı umuyorum.

Ne görmek istiyorum

  • Daha fazla ön uç tasarımcısının React'in ön uç kısmını öğrenmeye başladığını görmeyi umuyorum (Ve / veya diğer JS çerçeveleri ve / veya web bileşenleri). Benzer şekilde, tüm React ve yardımcı çerçevelerini öğrenmek zorunda değilsiniz, ancak JS kodunun bu ortamlara mükemmel işaretleme, stil ve sunum sağlamanıza izin veren bölümlerini öğrenmeniz gerekir. Bunu yapmak, son ürüne çok gerçek ve önemli bir şekilde doğrudan katkıda bulunmanıza olanak tanır.

  • Ön uç geliştirmenin ön uç geliştiricilerinin ön uç tasarımının önemini anladığını ve kod tabanında ön uç geliştiriciler için yer açtığını görmek isterim. Elbette, her şey şu anda büyük bir Javascript çatısı altında gerçekleşiyor, ancak bu ölçeği kavramak çok önemli, bu nedenle diğer becerilerin katkılarını memnuniyetle karşıladığından emin olmak için elinizden gelenin en iyisini yapın.

  • Tüm kutsal şeylere duyduğumuz sevgiden dolayı, lütfen uygulama kodu veya kullanıcı arayüzü kodu konusunda uzmanlaşmış profesyonellerin değerli olduğunu unutmayın. Herhangi bir kuruluş, yalnızca "tam yığın geliştiricileri" işe aldığınızı iddia etmemeli, bazı uzman personeli işe almalıdır. Yapılacak çok iş var. Herhangi bir ön uç ön uç, tam zamanlı çalışmayı içerir ve ön ucun arka uç kısmı şüphesiz aynıdır. Bu nedenle, sadece tüm işi iyi yapabilen genelcilerden ziyade, kendi alanlarında uzmanlıklarını icra edebilecek uzmanları işe almak daha iyidir.

  • Organizasyon / endüstri düzeyinde daha fazla nüans görmeyi umuyorum. "Bir React geliştiricisi işe alıyoruz" derken neyi kastediyorsunuz? "React geliştiricileri" neredeyse "front-end geliştiriciler" kadar belirsizdir, bu yüzden lütfen açıklığa kavuşturun. Markalama ve stil verme konusunda uzmanlaşmış birini mi arıyorsunuz? Ara yazılım ve iş mantığı yazan var mı? Veri ve veritabanlarını yöneten var mı? Oluşturma sürecinden sorumlu kişi mi? Cevap "yukarıdakilerin tümü" ise, lütfen yukarıdaki profesyonellerin görüşlerine bakın.

  • "Saf Javascript" ve "her şey bir bileşendir" günümüzde her yerde olduğundan, bu ortamlarda dikkatli olun Dikkat Ayrılık, dikkatli düşünmeyi ve büyük dikkat gerektirir. Yine, bu nüansla ilgili. UI bileşen kitaplığını ayrı bir ürün olarak yönetme fikrini gerçekten seviyorum, çünkü bu, ön ucun ön ucu ile ön ucun arka ucu arasındaki farkı çok açık hale getiriyor. Ancak bu yola gitmeseniz bile, projenizi net bir şekilde, yani kullanıcı arayüzü merkezli kod ile uygulama merkezli kod arasında net bir ayrım yaptığınızdan emin olun. En önemlisi, farklı becerilere sahip kişiler için kod tabanında yer açın.

  • "React'i sevmiyorsan, kullanma" demeyi bırak saçmalık, bu böyle yürümez. Bu kararları ben vermiyorum, kullandığımız teknolojiyi seçen ekiple çalışıyorum. Çünkü insanları dışlamak yerine farklı beceri gruplarından insanların katılımını teşvik eden bir ortam yaratmak daha iyidir.

  • Bu kitaplıkları öğrenmeniz önemli değil ama tam yığın 10x geliştirici ninja savaşçısı olmayı planlamayın. Hiç şüphe yok ki, arka uç geliştirme çalışması yapabilen birçok ön uç geliştirici var. tersine. Hiç şüphe yok ki birçok insan tüm bunları yapmayı arzuluyor. Harika! Ama burada söylemek istediğim şey, uzman olmanın yanlış bir tarafı olmadığı. Yine, yapılacak çok iş varken, bu kalkınma dünyasında herkesi barındıracak kadar alan var.

Bu ilginç bir öğrenme yolculuğu ve öğrenmeye ve gelişmeye devam etmeyi dört gözle bekliyorum.

Orijinal: http : // bradfrost .com / blog / post / frontend-design-react-and-a-bridge-over- -great-divide /

Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.

SON

Boom out 8-0 kilit kazanın! Japonya'nın ilk Asya Oyunları şampiyonu Kento Momota sezonun beşinci tacını kazandı
önceki
Haber Bülteni: Python önemli bir "siyah malzeme" olmuştur! Programcı: Madden
Sonraki
İkinci bir "Google" ı taklit edebilir mi?
"Teknoloji odaklı inovasyon" kurumsal gelişim için yeni bir yön haline geliyor. Geliştiriciler kendilerini nasıl uygulamalı?
Go dili on yıldır kuruldu, Go2 kullanıma hazır
Alt veritabanı ve alt tablo nasıl doğru bir şekilde alınır?
Büyük veri çağı burada, geliştiriciler nasıl saldırmalı?
Bu dizi Marvel DC'yi tamamen kararttı ve sonra bir dizi oldu
Fotoğraflar: Yakışıklı "Küçük K" Krist Stewart
Bazıları Netflix'in bu tür bir dizi yapmanın çılgınca olduğunu söylüyor, ben ısrar edersem çılgınca diyorum.
Fotoğraflar: VOGUE Eylül sayısının İngilizce baskısı, 2019'un çehresini değiştiriyor
Tek bir oyunda sadece 10 puan + 2 oyunda geri alındı! Chen Yufei 0-2 Olimpiyat ikincisi, milli takımın 3 ana oyuncusu elendi
Performans, GPU'dan 100 kat daha yüksek! İlk programlanabilir memristor AI bilgisayarı piyasaya sürüldü
Horton'ın takım arkadaşları öldü mü? 20 yaşındaki Avustralyalı yüzücü altın madalyalı kendi kendine onaylı uyuşturucu testi pozitif, CNN: Çok utanç verici
To Top