Programcılar React geliştirmenin altın kurallarında nasıl ustalaşır? | Teknik Başlıklar
Bu makalede, React'in "altın kuralı", ekran bileşenleri ve konteyner bileşenlerinin mevcut kavramlarına yeni bir bakış açısıdır.
Yazar | Rico Kahler
Çevirmen | Su Benru
Editör | Tu Min
Üretildi | CSDN (ID: CSDNnews)
Aşağıdaki çeviridir:
Son zamanlarda, bileşenleri geliştirirken yeni bir fikir edindim. Bu mutlaka yeni bir fikir değil, orijinal düşünme biçimine ince bir uyum. Bu yeni fikir:
Bileşen geliştirmenin altın kuralı
Bileşenleri en doğal şekilde oluşturun ve tanımlayın, sadece çalışması için neye ihtiyaç duyduklarını düşünün.
Tekrar açıklığa kavuşturmak gerekirse, bu orijinal düşünce tarzına ince bir ayarlamadır.Onu takip ettiğinizi düşünebilirsiniz, ancak onu ihlal etmek kolaydır.
Örneğin, aşağıdaki PersonCard bileşenine sahip olduğunuzu varsayalım:
Bu bileşeni "doğal olarak" tanımlamak istiyorsanız, aşağıdaki API'yi yazabilirsiniz:
PersonCard.propTypes = { isim: PropTypes.string.isRequired, jobTitle: PropTypes.string.isRequired, pictureUrl: PropTypes.string.isRequired, };"Doğal" PersonCard API
Çok basit görünüyor. Bakalım PersonCard bileşeninin çalışması için gereken özellikler. Burada, PersonCard bileşeni yalnızca ad, başlık ve fotoğraf URL'sine ihtiyaç duyar.
Ancak "resmi fotoğrafların kullanıcı ayarlarına göre gösterilip gösterilmeyeceğine karar verme" işlevini anlamanız gerektiğini varsayalım. Bunun gibi bir API yazmayı deneyebilirsiniz:
PersonCard.propTypes = { isim: PropTypes.string.isRequired, jobTitle: PropTypes.string.isRequired, officialPictureUrl: PropTypes.string.isRequired, pictureUrl: PropTypes.string.isRequired, PreferOfficial: PropTypes.boolean.isRequired, };Karmaşık PersonCard API
Görünüşe göre bu karmaşık bileşen, işlevini gerçekleştirmek için bu ekstra aksesuarlara ihtiyaç duyuyor, ancak aslında, yukarıdaki bileşen farklı görünmüyor ve bu ekstra aksesuarlara da ihtiyaç duymuyor. Bu ekstra özniteliklerin yaptığı şey, bu PreferOfficial ayarını bileşenle birleştirmektir, ancak bunu yapmak, bu bileşeni başka durumlarda (örneğin, hiçbir resmi fotoğrafın gerekli olmadığı) kullanmayı çok "doğal olmayan" hale getirecektir.
Konteynerin rolü
Öyleyse, "hangi fotoğraf URL'sinin görüntüleneceğine karar verme" mantığı bu bileşenin kendisine ait değilse, nereye ait olmalıdır?
Bunun yerine bir dizin dosyası kullanmaya ne dersiniz?
Her bileşenin kendi adını taşıyan bir klasöre yerleştirildiği bir klasör yapısını benimsedik ve dizin dosyası "doğal bileşenlerinizi" dış dünya ile köprülemekten sorumludur. Bu dosyaya "konteyner" diyoruz (React Redux'un konteyner bileşenleri konseptinden esinlenerek: https://redux.js.org/basics/usage-with-react#presentational-and-container-components).
/ Kişi Kartı -PersonCard.js ------ "doğal" bileşen -index.js ----------- "kapsayıcı"konteyner: Bir konteyneri, doğal bileşeniniz ile dış dünya arasına yerleştirilmiş küçük bir kod parçası olarak tanımlıyoruz (bu iki parçayı birbirine bağlamaktan sorumlu). Bu nedenle bazen bunlara "konteynırlar" "enjektörler" de diyoruz.
Doğal bileşenler: Sizden bir fotoğraf istenirse, "doğal bileşenleriniz" bu fotoğrafı görüntülemek için kullanılan kodlardır. Verilerin nasıl elde edileceğini veya uygulamanın neresinde olduğunu bilmenize gerek yoktur, ihtiyacınız olan her şey Bildiğim şey işe yaraması gerektiği.
Dış dünya: Bu, uygulamanızın (Redux Mağazası gibi) sahip olduğu tüm kaynakları ifade eder ve bu kaynaklar, doğal bileşenlerinizi karşılayacak şekilde dönüştürülebilen desteklerdir.
Bu makalenin hedefleri: "Doğal" bileşenleri nasıl yazarız ve dış dünyadan gelen çöplerle kirlenmemelerini nasıl sağlarız? Bu neden daha iyi?
Not: Bu makaledeki "kap" kavramı, bu iki bağlantıdaki (Dan Abramov ve React Redux) terimlerden esinlense de, bu makaledeki "kapsayıcı" tanımı biraz farklıdır.
Dan Abramov'un kabı ile bu makaledeki kap arasındaki tek fark kavramsal düzeyde. Dan makalesinde iki tür bileşen olduğunu söyledi: ekran bileşenleri ve kap bileşenleri. Bu yazıda, onu bir adım daha ileri götürüyor ve bileşenlere ve kaplara ayırıyoruz.
Kapsayıcıları uygulamak için bileşenleri kullansak bile, kapları kavramsal düzeyde bileşenler olarak düşünmüyoruz. Bu nedenle, kapsayıcıyı dizin dosyasına koymanızı öneririz, çünkü bu, bağımsız değil, doğal bileşenleriniz ile dış dünya arasında bir köprüdür.
Bu makalenin odak noktasının bileşenler olduğunu fark edebilirsiniz, ancak yerin çoğunu kaplar kaplar. neden
Bunun nedeni, doğal bileşenleri yazmanın daha kolay ve daha ilginç olmasıdır. Ve bileşenlerinizin dış dünyaya (konteynerin işi) bağlanmasını sağlamak biraz zor.
Bana göre, "doğal bileşenlerinizin" dış dünyadan gelen çöplerle kirletilmesinin üç ana nedeni var:
Daha sonra, yukarıdaki üç senaryoyu açıklamak için farklı tipte konteyner uygulama örnekleri kullanmaya çalışacağım.
Garip veri yapıları kullanın
Bazen gerekli bilgileri sağlamak için farklı veri türlerinin birbirine bağlanması ve daha makul bir biçime dönüştürülmesi gerekir. Daha uygun bir kelime olmadığı için burada "garip" kelimesini kullandım. "Garip veri yapısı", bileşeninizin "doğal olmayan" kullanmasına neden olan veri yapısı türüdür.
"Garip" veri yapılarını doğrudan bileşene geçirmek ve bileşen içinde dönüştürmek çok caziptir, ancak bu karışıklığa neden olabilir ve genellikle bileşen testini zorlaştırır.
Son zamanlarda, bir bileşen oluşturmak ve belirli bir form türünü desteklemek için kullandığımız belirli bir veri yapısından veri almak için görevlendirildim, kendimi bu tuzağa düşerken buldum (aşağıdaki örnek).
Bu bileşen, bu garip veri yapısı alanını bir destek olarak ele alır. Aslında, gelecekte bu bileşeni artık kullanmazsak, bu kabul edilebilir. Fakat daha sonra bu bileşen, bu garip veri yapısıyla ilgisi olmayan bir yerde tekrar kullanıldı, bu yüzden gerçek bir sorun haline geldi.
Bileşenler bu veri yapısını gerektirdiğinden, onu yeniden kullanmak imkansız hale gelir ve onu yeniden düzenlemek zordur. İlk olarak yazdığımız test programı da kafa karıştırıcıydı çünkü bu garip veri yapısını simüle etti. Bu test programlarını anlayamayız ve nihayet yeniden düzenlendiklerinde onları yeniden yazamayız.
Ne yazık ki, garip veri yapıları kaçınılmazdır, ancak kapsayıcılar kullanmak bunlarla başa çıkmanın harika bir yoludur. Bu örnekten öğrendiğim bir şey, bileşenleri bu şekilde oluşturmanın size bileşenleri ayıklama ve yeniden kullanılabilir bileşenlere dönüştürme seçeneği sunduğudur. Ancak bir bileşene garip bir veri yapısı aktarırsanız, bu seçimi kaybedersiniz.
Not: Yazdığınız tüm bileşenlerin başından itibaren evrensel olmasını önermiyorum. Aksine, bileşeninizin temelde neyi başardığını düşünmeniz ve ardından boşluğu doldurmanız önerilir. Bunu yaparsanız, bileşenlerinizi yeniden kullanılabilir bileşenlere dönüştürmeyi seçersiniz, bu da az miktarda çalışma gerektirir.
Kapsayıcıları uygulamak için işlevsel bileşenleri kullanın
Sahne donanımlarını kesin olarak eşliyorsanız, bunu başarmanın basit bir yolu, işlevsel bileşenleri kullanmaktır:
React'ten React'i içe aktar '; PropTypes'i 'prop-tiplerinden' içe aktarın; getValuesFromField'ı './ helpers / getValuesFromField'den içe aktarın'; import transformValuesToField './ helpers / transformValuesToField'; ChipField'ı './ ChipField'den içe aktarın; varsayılan işlevi ChipFieldContainer ({field, onEditField}) { const değerler = getValuesFromField (alan); function handleOnChange (değerler) { onEditField (transformValuesToField (değerler)); } dönüş < ChipField değerleri = {değerler} onChange = {handleOnChange} / > ; } // dış sahne ChipFieldContainer.propTypes = { alan: PropTypes.object.isRequired, onEditField: PropTypes.func.isRequired, };Bileşenin klasör yapısı şu şekildedir:
/ ChipField -ChipField.js ------------------ "doğal" çip alanı -ChipField.test.js -index.js ---------------------- "kapsayıcı" -index.test.js / helpers ----------------------- yardımcılar / utils için bir klasör -getValuesFromField.js -getValuesFromField.test.js -transformValuesToField.js -transformValuesToField.test.js"Bu uygulamada yapılacak çok iş var" diye düşünüyor olabilirsiniz. Böyle düşüncelere sahip olmanız normaldir. Evet, burada yapılacak çok iş var gibi görünüyor, çünkü daha fazla dosyanın bakımı gerekiyor ve o kadar sezgisel görünmüyor. Ancak bir noktayı gözden kaçırmış olabilirsiniz:
Aslında, gerçek iş yükü artmamıştır.İster veriyi bileşenin dışında ister bileşenin içinde dönüştürüyor olun, iş yükü aslında aynıdır. Tek fark, veri dönüşümünü bileşenin dışına koyduğunuzda, veri dönüşümünüzün doğru olup olmadığını daha doğru bir şekilde test edebilir ve aynı zamanda endişeleri ayırabilirsiniz.
Bileşenlerin dışında gereksinimleri uygulayın
Yukarıda bahsedilen PersonCard örneği için, ona bileşen geliştirmenin "altın kuralı" nı uyguladığınızda, bazı gereksinimlerin gerçek bileşenin kapsamı dışında olduğunu fark etmeniz olasıdır. Peki bu gereksinimler nasıl gerçekleştirilecek?
Cevabı tahmin etmeliydin: evet, bir kap kullan.
Bileşenleri doğal tutmak için kaplar oluşturarak fazladan iş yapabilirsiniz. Bunu yaptığınızda, daha basit ve tek işlevli bir bileşen ve daha iyi bir test kabı elde edersiniz.
Bir PersonCard kapsayıcısının uygulanmasını gösterelim.
Üst düzey bileşenler kullanarak kapsayıcılar uygulayın
React Redux, Redux Mağazasından nesnelerin itilmesi ve haritalanması için bir konteyner uygulamak üzere üst düzey bileşenler kullanır. "Kapsayıcı" terimi React Redux'ten türetildiği için, React Redux'un bağlantısının bir kapsayıcı olması şaşırtıcı değildir.
İster nesneleri eşlemek için işlevsel bileşenler kullanın, ister Redux Mağazasına bağlanmak için üst düzey bileşenler kullanın, altın kural ve konteynerlerin rolü aynıdır. Önce doğal bileşenlerinizi yazın, ardından boşluğu doldurmak için üst düzey bileşenleri kullanın.
'react-redux'dan {connect} içe aktar; getPictureUrl dosyasını './ helpers / getPictureUrl'den içe aktarın; PersonCard'ı './ PersonCard'dan içe aktarın; const mapStateToProps = (durum, ownProps) = > { const {kişi} = ownProps; const {name, jobTitle, customPictureUrl, officialPictureUrl} = kişi; const {preferOfficial} = durum.settings; const pictureUrl = getPictureUrl (preferOfficial, customPictureUrl, officialPictureUrl); return {name, jobTitle, pictureUrl}; }; const mapDispatchToProps = null; varsayılan bağlantıyı dışa aktar ( mapStateToProps, mapDispatchToProps, ) (Kişi Kartı);Üst düzey bileşenler kullanarak konteyner uygulaması
Yukarıdaki uygulamanın klasör yapısı aşağıdaki gibidir:
/ Kişi Kartı -PersonCard.js ----------------- doğal bileşen -PersonCard.test.js -index.js ---------------------- kapsayıcı -index.test.js / helpers -getPictureUrl.js ------------ yardımcısı -getPictureUrl.test.jsNot: Bu örnekte, / helpers klasöründe yalnızca bir getPictureURL vardır.Gerçek durumda başka yardımcılar da olmalıdır. Bu, bu mantığı ayırabileceğiniz bir gösterimdir. Klasör yapısının, kapsayıcı uygulamasından bağımsız olarak aslında aynı olduğunu da fark edebilirsiniz.
Redux ile deneyiminiz varsa, yukarıdaki örneğe zaten aşina olabilirsiniz. Burada yine altın kural yeni bir fikir değil, orijinal düşünce tarzına ince bir uyumdur.
Ek olarak, üst düzey bileşenlere sahip bir konteyner uyguladığınızda, üst düzey bileşenleri işlevsel olarak bir araya getirebilirsiniz, yani bir üst düzey bileşenden diğerine sahne aktarabilirsiniz. Geçmişte, tek bir konteyner uygulamak için birden fazla üst düzey bileşeni birbirine bağlardık.
Not: React topluluğu, üst düzey bileşenlerden uzaklaşıyor gibi görünüyor.
Ben de aynısını tavsiye ederim. Üst düzey bileşenleri kullanmaktan edindiğim deneyim, işlevsel bileşenlere aşina olmayan ekip üyeleri için bunların kafa karıştırıcı olabileceği ve sözde "kapsülleme cehennemine" yol açabileceği, yani bileşenlerin birçok kez kapsüllenerek sonuçlanacağıdır. Ciddi performans sorunları.
Burada referans için bazı ilgili makaleleri ve kaynakları listeliyorum:
- Hooks talk (2018): https://youtu.be/dpw9EHDh2bM?t=710
- Konuşmayı yeniden oluşturun (2016): https://youtu.be/zD_judE-bXk?t=1101
- Bir Oluşturma Prop kullanın! (2017): https://cdb.reacttraining.com/use-a-render-prop-50de598f11ce
- Render Props (2018) ne zaman KULLANILMAMALIDIR: https://blog.kentcdodds.com/when-to-not-use-render-props-5397bbeff746
Peki, React Hooks hakkında konuşma zamanımız geldi.
Kapsayıcıları uygulamak için kancaları kullanın
Bu makalede neden Hook'lardan bahsedildiğini sorabilirsiniz, çünkü Hook'ları kullanarak konteynerleri uygulamak çok daha kolaydır.
React Hooks'a aşina değilseniz, Dan Abramov ve Ryan Florence'ın React 2018 konferansındaki konuşmasını izlemenizi öneririm.Video, React Hooks'un konsept tanıtımını içerir (https://youtu.be/dpw9EHDh2bM).
Kısacası, React ekibi, üst düzey bileşenlerin ve benzer modellerin neden olduğu sorunların üstesinden gelmek için Hook'ları tanıttı. React Hooks, bunların yerini almayı ve çoğu senaryoda en iyi çözüm olmayı amaçlamaktadır.
Bu, bir fonksiyon bileşeni ve Hook'lar kullanarak bir konteyner uygulayabileceğimiz anlamına gelir.
Aşağıdaki örnekte, "dış dünyayı" temsil etmek için iki kanca, useRoute ve useRedux kullanıyoruz ve "dış dünyayı" doğal bileşenleriniz için mevcut olan desteklerle eşlemek için yardımcı getValues'i kullanıyoruz. Ayrıca bu yardımcıyı transformValues'i, bileşenin çıktısını gönderim tarafından temsil edilen dış dünyaya dönüştürmek için kullanırız.
React'ten React'i içe aktar '; PropTypes'i 'prop-tiplerinden' içe aktarın; 'react-yönlendiriciden {useRouter} öğesini içe aktarın '; 'react-redux'dan {useRedux} dosyasını içe aktarın; actionCreator'ı 'redux-malzemeleriniz'den içe aktarın; getValues öğelerini './ helpers / getVaules'den içe aktarın; './ helpers / transformValues' öğesinden transformValues içe aktarın; './ FooComponent' öğesinden FooComponent içe aktarın; varsayılan işlevi FooComponentContainer (props) dışa aktar { // kancalar const {match} = useRouter ({yol: / * ... * /}); // NOT: `useRedux` henüz mevcut değil ve muhtemelen böyle görünmeyecek const {durum, dispatch} = useRedux (); // eşleme const props = getValues (durum, eşleşme); function handleChange (e) { const dönüştürülmüş = transformValues (e); dispatch (actionCreator (dönüştürülmüş)); } // doğal bileşen dönüş < FooComponent {... props} onChange = {handleChange} / > ; } FooComponentContainer.propTypes = {/ * ... * /};Kapsayıcıları uygulamak için kancaları kullanın
Referans klasör yapısı aşağıdaki gibidir:
/ FooComponent ----------- diğerlerinin içe aktarması için tüm bileşen -FooComponent.js ------ bileşenin "doğal" kısmı -FooComponent.test.js -index.js ------------- boşluğu dolduran "kapsayıcı" -index.js.test.js ve bağımlılıklar sağlar / helpers -------------- kolayca test edebileceğiniz izole yardımcılar -getValues.js -getValues.test.js -transformValues.js -transformValues.test.jsKapsayıcıdaki olayları tetikleyin
Doğal bileşenlerden sapan son durum, genellikle bileşen montajı ve bileşen destekleri ile ilgili bir olayın tetiklenmesi gerektiğinde ortaya çıkar.
Örneğin, göreviniz bir "gösterge tablosu" işlevi geliştirmektir. Tasarım ekibi bir "gösterge tablosu" şablonu verdi ve siz bunu bir React bileşenine dönüştürdünüz. Şimdi bu "gösterge tablosunu" verilerle doldurmalısınız.
Bu bileşeni bağladığınızda, verileri almak için bir işlev (dispatch (fetchAction) gibi) çağırmanız gerektiğini fark edersiniz.
Bu senaryoda, iki yaşam döngüsü yöntemi, componentDidMount ve componentDidUpdate ekledim ve bileşeni dış dünyayla bağlamak için tetiklenecek bazı olaylara ihtiyacım olduğu için onMount veya onDashboardIdChanged olmak üzere iki sahne ekledim.
Altın kurala göre, onMount ve onDashboardIdChanged öğelerinin ikisi "doğal değildir", bu nedenle konteynere yerleştirilmeleri gerekir.
Hook'ları kullanmanın avantajı, bileşenler monte edildiğinde (onMount) veya bileşen propsları güncellendiğinde olayları dağıtmayı kolaylaştırmasıdır!
Bileşen takıldığında olay tetiklemesi:
Bileşen monte edildiğinde bir olayı tetiklemek için, Hook useEffect'i gelen bir parametre olarak boş bir diziyle çağırmanız gerekir (aşağıdaki şekilde gösterildiği gibi).
React'i içe aktar, {useEffect} from'react '; PropTypes'i 'prop-tiplerinden' içe aktarın; 'react-redux'dan {useRedux} dosyasını içe aktarın; fetchSomething_reduxAction'ı 'redux-öğeleriniz'den içe aktarın; getValues öğelerini './ helpers / getVaules'den içe aktarın; './ FooComponent' öğesinden FooComponent içe aktarın; varsayılan işlevi FooComponentContainer (props) dışa aktar { // kancalar // NOT: `useRedux` henüz mevcut değil ve muhtemelen böyle görünmeyecek const {durum, dispatch} = useRedux (); // onMount eylemi gönder useEffect (() = > { dispatch (fetchSomething_reduxAction); },); // boş dizi yalnızca binek üzerinde ateşleneceğini söyler // https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects // eşleme const props = getValues (durum, eşleşme); // doğal bileşen dönüş < FooComponent {... props} / > ; } FooComponentContainer.propTypes = {/ * ... * /};Olay, Hooks bileşeni monte edildiğinde kapta tetiklenir
Bileşen özelliği güncellendiğinde tetiklenen olay:
UseEffect Hook, özellik güncellendiğinde sağladığınız işlevi yeniden oluşturma ve çağırma arasındaki özellik değişikliklerini kontrol edebilir.
Hook useEffect'i kullanmadan önce, bileşene "doğal olmayan" bir yaşam döngüsü yöntemi ve OnPropertyChanged özelliği eklerken buldum, çünkü bileşen dışındaki özelliklerin farkını karşılaştırmanın bir yolu yoktu (örnek aşağıdaki gibidir):
React'ten React'i içe aktar '; PropTypes'i 'prop-tiplerinden' içe aktarın; / ** * "UseEffect" ten önce kendimi "doğal olmayan" sahne eklerken buldum * Yalnızca sahne farklı olduğunda olayları tetikleyen bileşenlerime. * * Bileşenin "render" öğesinin "id" kullanmadığını fark ettim * çoğu zaman * / varsayılan sınıfı dışa aktar BeforeUseEffect, React.Component { statik propTypes = { id: PropTypes.string.isRequired, onIdChange: PropTypes.func.isRequired, }; componentDidMount () { this.props.onIdChange (this.props.id); } componentDidUpdate (prevProps) { if (prevProps.id! == this.props.id) { this.props.onIdChange (this.props.id); } } render () { dönüş // ... } }Eski yöntem: özellikler güncellendiğinde olayları tetiklemek için sınıfları kullanın
Artık Hook useEffect ile, gerçek bileşene gereksiz sahne eklemeden, sahne öğeleri güncellendiğinde olay tetiklemeyi uygulamak için çok hafif bir yöntem vardır (örnekler aşağıdaki gibidir).
React'i içe aktar, {useEffect} from'react '; PropTypes'i 'prop-tiplerinden' içe aktarın; 'react-redux'dan {useRedux} dosyasını içe aktarın; fetchSomething_reduxAction'ı 'redux-öğeleriniz'den içe aktarın; getValues öğelerini './ helpers / getVaules'den içe aktarın; './ FooComponent' öğesinden FooComponent içe aktarın; varsayılan işlevi FooComponentContainer ({id}) { // kancalar // NOT: `useRedux` henüz mevcut değil ve muhtemelen böyle görünmeyecek const {durum, dispatch} = useRedux (); // onMount eylemi gönder useEffect (() = > { dispatch (fetchSomething_reduxAction); },); // "useEffect" bu "id" pervanesini izleyecek ve farklı olduğunda etkiyi ateşleyecektir // https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects // eşleme const props = getValues (durum, eşleşme); // doğal bileşen dönüş < FooComponent {... props} / > ; } FooComponentContainer.propTypes = { id: PropTypes.string.isRequired, };Yeni yöntem: öznitelikler güncellendiğinde olay tetiklemeyi uygulamak için hook useEffect kullanın
Sorumluluk reddi: useEffect kancasını kullanmanın yanı sıra, kapsayıcıdaki diğer üst düzey bileşenleri kullanmanın başka yolları da vardır (örneğin, yeniden oluşturma yaşam döngüsü örneği: https://github.com/acdlite/recompose/blob/3db12ce7121a050b533476958ff3d66ded1c4bb8/docs/API.mdocs/API #lifecycle) nesnelerdeki farklılıkları karşılaştırmak veya bir yaşam döngüsü bileşeni oluşturmak için (örneğin, react yönlendiricisinde uygulanan bir örnek: https://github.com/ReactTraining/react-router/blob/89a72d58ac55b2d8640c25e86d1f1496e4ba8d6c/packages/react-router/modules Lifecycle.js), ancak bu yöntemler ekip üyelerinin kafasını karıştırır veya geleneksel olmayan uygulamalardır.
Bunun faydaları nelerdir?
Bileşen geliştirme eğlencesinin tadını çıkarın
Benim için bileşen geliştirme, ön uç geliştirmenin en ilginç ve eğlenceli kısmı. Ekibinizin fikirlerini ve hayallerini gerçek bir deneyime dönüştürebilirsiniz. Bu iyi bir duygu. Bence bunları ekip içinde paylaşmalıyız çünkü her birimizle alakalı.
Bileşen API'nizin ve deneyiminizin "dış dünya" tarafından yok edildiği senaryo asla görünmeyecektir. Benim en sevdiğim altın kuralım, ek sahne olmadan tam istediğiniz gibi bileşeninizdir.
Test etme ve yeniden kullanım için daha fazla fırsat
Bu mimari ile, temelde işleme sırasında yeni bir veri katmanı sunarsınız. Ve bu "katman" da, odağınızı bileşene giren verilerin doğruluğu ile bileşenin çalışma şekli arasında değiştirebilirsiniz.
Bilseniz de bilmeseniz de, bu katman uygulamanızda zaten mevcuttur, ancak sunum mantığı ile birleştirilebilir. Bu katmanı oluşturduğumda, çok fazla kod optimizasyonu yapabildiğimi ve birçok mantığı yeniden kullanabildiğimi, aksi takdirde bu mantığı ortak noktayı bilmeden yeniden yazabileceğimi buldum.
Bazı özel Hook'lar ekleyerek, bu faydalar daha belirgin hale gelecektir. Özelleştirilmiş Kancalar, bize mantığı çıkarmak ve yardımcı işlevler tarafından yapılamayan harici güncellemeleri desteklemek için daha basit bir yol sağlar.
Ekip çıktısını en üst düzeye çıkarın
Bir ekip birlikte çalıştığında, konteyner geliştirme ve bileşen geliştirme çalışmalarını farklı ekip üyelerine dağıtabilirsiniz. API spesifikasyonu belirlenmişse, aşağıdaki üç bölümün geliştirme çalışması aynı anda gerçekleştirilebilir:
İstisnalar var mı?
Tıpkı gerçek altın kural gibi, buradaki altın kural da altın bir kuraldır. Bazı senaryolarda, belirli dönüşümlerin karmaşıklığını azaltmak için görünüşte doğal olmayan bileşen API'leri yazmak da mantıklıdır.
Basit bir örnek, sahne öğelerinin adıdır. Geliştiriciler sahne donanımlarını daha "doğal" nedenlerle yeniden adlandırırsa, işleri daha karmaşık hale getirecektir.
Bu yasaya aşırı vurgu yapmak mümkündür ve sonuçta takılıp kalabilirsiniz.
son sözler
Bu makaledeki "Altın Kural", ekran bileşenleri ve kap bileşenlerinin mevcut kavramlarına yeni bir bakış açısıdır. Bileşeninizin tam olarak ne yapacağını bilirseniz, daha basit ve daha okunaklı bir bölüm elde edebilirsiniz!
Orijinal: https://medium.freecodecamp.org/how-the-golden-rule-of-react-components-can-help-you-write-better-code-127046b478eb
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
