e
sv

React için 12 temel ESLint kuralı

avatar

Yazılım Method

  • e 0

    Mutlu

  • e 0

    Eğlenmiş

  • e 0

    Şaşırmış

  • e 0

    Kızgın

  • e 0

    Üzgün

giriiş

ESLint, JavaScript kodu için, stil seçimlerini kapsayan ve yaygın hataları önleyen kapsamlı bir kurallar dizisine sahiptir. ESLint'i tek başına kullanmak projenizi hızlandıracaktır, ancak katı React uygulamaları yazmanıza yardımcı olacak React'e özel kurallar eklemek için kullanılabilecek ESLint eklentileri vardır.

Bu gönderide, Hooks için geçerli olanları da dahil olmak üzere bu ESLint kurallarını ve eklentilerini gözden geçireceğiz. Atlamanız için bazı hızlı bağlantılar:

React Hooks kuralları ( eslint-plugin-react-hooks )

Bu eklenti yalnızca iki kural içerir, ancak bunlar Hooks ile fonksiyon bileşenleri yazarken yaygın tuzaklardan kaçınmak için kritik öneme sahiptir.

Tepki kancaları/kanca kuralları

Bu kural, bileşenlerin Kancaları kullanırken Kanca Kurallarına uymasını zorunlu kılar. Kurallar, React belgelerinde ayrıntılı olarak tartışılmıştır, ancak Hook'ları kullanırken uyulması gereken iki kural vardır:

  1. Kancalar yalnızca bileşeninizin üst düzey kodundan çağrılmalıdır. Bunun gerçekten anlamı, Kancaların koşullu olarak çağrılmaması gerektiğidir – bunun yerine sorunlardan ve ince hatalardan kaçınmak için her işlemede aynı sırayla çağrılmaları gerekir.
  2. Kancalar yalnızca bir işlev bileşeninden veya başka bir Kancadan çağrılmalıdır.
    1. Özel Kancalar, genellikle yerleşik, hatta diğer özel Kancalardan birlikte davranış oluşturur.

Varsayılan yapılandırmada, bu kuralın ihlali bir hataya neden olarak tiftik kontrolünün başarısız olmasına neden olur.

tepki kancaları/kapsamlı-deps

Bu kural, Hooks'a geçirilen bağımlılık dizisinin içeriği hakkında useEffect , useCallback ve useMemo gibi belirli kuralları zorlar. Genel olarak, efekt, geri çağırma veya not alınan değer hesaplamasında başvurulan herhangi bir değer, bağımlılık dizisine dahil edilmelidir. Bu düzgün yapılmazsa, güncel olmayan durum verileri veya sonsuz işleme döngüleri gibi sorunlar ortaya çıkabilir.

Bu kural, bağımlılıkla ilgili olası hataları bulmakta iyidir, ancak bazı sınırlamalar vardır:

  • Bağımlılık dizilerine sahip Özel Kancalar bu kuralla kontrol edilmeyecektir. Yalnızca dahili Kancalar için geçerlidir
  • Kural, yalnızca statik bir değerler dizisiyse bağımlılıkları doğru şekilde kontrol edebilir. Başka bir diziye başvuru kullanılırsa veya buna başka bir dizi yayılırsa, kural bağımlılıkları belirleyemediğine dair bir uyarı verir.

Bu kural biraz tartışmalı olmuştur; GitHub'da birkaç uzun konu var, ancak React ekibi geri bildirim istemek ve dahil etmek konusunda iyi. Varsayılan yapılandırmada, bu kuralın ihlali uyarı olarak değerlendirilir.

Bu kuralın ayrıntıları tek başına bütün bir makaleyi kaplayabilir. Bu kural ve nasıl düzgün bir şekilde kullanılacağı hakkında daha ayrıntılı bilgi için LogRocket blogunda yer alan React kapsamlı-deps linting uyarısını anlama makalesine bakın.

Tepki kuralları ( eslint-plugin-react )

Bu eklenti, React'in özüne özgü çok daha fazla kural (yazma sırasında 100 kural) içerir. Kuralların çoğu genel React uygulamalarını kapsar ve diğerleri JSX sözdizimi ile ilgili sorunları kapsar. Daha faydalı olanlardan bazılarına bir göz atalım.

tepki/düğme-tipi

Erişilebilirlik nedenleriyle, bir bileşendeki başka bir URL'ye basit bağlantılar olmayan çoğu tıklanabilir öğe, düğmeler olarak uygulanmalıdır . Yaygın bir hata, form göndermek için kullanılmadıklarında bu düğmelerden type özniteliğini çıkarmaktır.

Hiçbir type belirtilmediğinde, bir düğme varsayılan olarak bir submit türü olur. Bu, bir form öğesinden gelen düğmeler için sorunlara neden olabilir. Bir formun içinde böyle bir düğmeyi tıklamak, potansiyel olarak istenmeyen bir form gönderimine neden olur.

Form göndermesi amaçlanmayan eylem düğmelerinin type özelliği button olmalıdır.

Bu kural, tüm düğmelerin açıkça bir type özniteliğine sahip olmasını zorunlu kılar – Gönder düğmeleri olarak tasarlananlar bile. Açık olmakla, kasıtsız gönderimlerden kaçınılır ve kodun amacı açıktır.

tepki/prop-tipleri

Tüm React bileşenlerinin bir PropTypes bildiriminde açıklanan prop'larına sahip olmasını gerektirir. Bu kontroller yalnızca geliştirme modunda hatalar atar, ancak bir bileşene geçirilen yanlış aksesuarlardan kaynaklanan hataların yakalanmasına yardımcı olabilir.

Projeniz TypeScript kullanıyorsa, bunları açıklayan bileşen props'larına bir tür ek açıklaması eklenerek bu kural da karşılanır.

Bu iki yaklaşım, Dillion Megida'nın React uygulamalarında TypeScript ve PropTypes'ı Karşılaştırma bölümünde ayrıntılı olarak ele alınmaktadır.

tepki/require-varsayılan-sahneler

Bileşene bağlı olarak, bazıları isteğe bağlıyken bazıları gerekli olabilir. Bir bileşene isteğe bağlı bir destek aktarılmazsa, undefined olacaktır. Bu beklenebilir, ancak değer kontrol edilmezse hatalara neden olabilir.

Bu kural, her isteğe bağlı pervaneye, bileşen için bir defaultProps bildiriminin içinde varsayılan bir değer verilmesini gerektirir. Bileşenin beklediği buysa, bu varsayılan değer açıkça null veya undefined olarak ayarlanabilir.

İşlev bileşenleriyle, varsayılan donanımları kontrol etmek için kullanılabilecek iki farklı strateji vardır:

defaultProps

Bu strateji, işlev bileşeninin varsayılanlarla birlikte bir defaultProps nesnesine sahip olmasını bekler.

 const MyComponent = ({ eylem }) => { ... }

MyComponent.propTypes = {
  Eylem: PropTypes.string;
};

MyComponent.defaultProps = {
  eylem: 'init'
};

varsayılan bağımsız değişkenler

Bu strateji, JavaScript'in yerleşik varsayılan değerler sözdizimini kullanarak varsayılanların işlev bildiriminde belirtilmesini bekler.

 const MyComponent = ({ action = 'init' }) => { ... }

MyComponent.propTypes = {
  Eylem: PropTypes.string;
};

defaultArguments stratejisini kullanırsanız, defaultProps nesnesi olmamalıdır. Varsa, bu kural başarısız olacaktır.

tepki/dizi yok-endeks anahtarı

React'te bir öğe listesi oluştururken, genellikle bir dizide map çağırırız ve eşleme işlevi bir bileşen döndürür. Listedeki her bir öğeyi takip etmek için React'in bu bileşenlerin bir key desteğine sahip olması gerekir.

Oluşturma listeleriyle ilgili yaygın bir tuzak, anahtar olarak dizi dizinini kullanmaktır. Bu, gereksiz ve hatta yanlış işlemelere neden olabilir. React belgeleri, neden olabileceği sorunlar nedeniyle bu uygulamaya karşı tavsiyede bulunur ( anahtarların nasıl kullanıldığı hakkında daha ayrıntılı bir tartışma da vardır). Bir anahtarın, bir veritabanı satırındaki birincil anahtar değeri gibi değişmeyen, liste içindeki o öğe için benzersiz bir tanımlayıcı olması beklenir.

Bu kural, dizi dizininin anahtar olarak kullanılmamasını sağlar.

tepki verme/jsx kapsamında tepki verme

Bu basit React bileşenini düşünün:

 const Greeter = ({ isim }) => <div>Merhaba {name}!</div>;

React nesnesine hiç başvuruda bulunulmadı. Ancak, React hala içe aktarılması gerekiyor, aksi takdirde bir hatayla karşılaşırsınız. Bu, JSX'in transpilasyon sürecinden kaynaklanmaktadır. Tarayıcılar JSX'i anlamaz, bu nedenle oluşturma işlemi sırasında (genellikle Babel veya TypeScript gibi bir araçla), JSX öğeleri geçerli JavaScript'e dönüştürülür.

Bu oluşturulan JavaScript kodu, JSX öğelerinin yerine React.createElement öğesini çağırır. Yukarıdaki bileşen şöyle bir şeye aktarılabilir:

 const Greeter = ({ isim }) => React.createElement("div", null, "Merhaba ", isim, "!");

Buradaki React referansları, React hala içe aktarılmasının neden gerekli olduğunu gösterir. Bu kural, JSX işaretlemesine sahip tüm dosyaların (bir React bileşeni olması gerekmez) kapsamında React'e sahip olmasını sağlar (tipik olarak bir import veya require çağrı yoluyla).

tepki/jsx-kullanım-tepki

Doğru aktarım için her zaman React'i içe aktarmak gerekir, ancak ESLint dosyaya baktığında hala JSX'tir, bu nedenle hiçbir yerde React başvurulduğunu görmez. Proje no-unused-vars kuralını kullanıyorsa, React içe aktarıldığından ancak hiçbir yerde kullanılmadığından bu bir hataya neden olur.

Bu kural bu durumu yakalar ve no-unused-vars React içe aktarmasında başarısız olmasını önler.

tepki/görünen ad

Doğru hata ayıklama çıktısı için tüm React bileşenlerinin bir görünen adı olmalıdır. Çoğu durumda, bu herhangi bir ekstra kod gerektirmez. Bir bileşen adlandırılmış bir işlevse, görünen ad işlevin adı olacaktır. Aşağıdaki örneklerde, bileşenin görünen adı MyComponent olacaktır.

  • const MyComponent = () => { … }
  • const MyComponent = function() { return …; }
  • export default function MyComponent() { return …; }

Otomatik görünen adın kaybolduğu bazı durumlar vardır. Bu genellikle, aşağıdaki iki örnekte olduğu gibi, bileşen bildirimi başka bir işlev veya daha yüksek dereceli bileşen tarafından sarıldığında olur:

  • const MyComponent = React.memo(() => { … });
  • const MyComponent = React.forwardRef((props, ref) => { … });

MyComponent adı, memo ve forwardRef tarafından döndürülen yeni "dış" bileşene bağlıdır. Bileşenin kendisinin artık görünen adı yok, bu da bu kuralın başarısız olmasına neden olacak.

Bu durumlar ortaya çıktığında, kuralı yerine getirmek için displayName özelliği aracılığıyla bir görünen ad manuel olarak belirtilebilir:

 const MyComponent = React.memo(() => { ... });
MyComponent.displayName = 'MyComponent';

tepki/çocuksuz-prop

React bileşenleri, children adı verilen özel bir desteği kabul eder. Bu desteğin değeri, öğenin açılış ve kapanış etiketlerinin içindeki içerik ne olursa olsun olacaktır. Bu basit MyList bileşenini düşünün:

 const MyList = ({ çocuklar }) => {
  <ul>{children}</ul> döndür;
};

Bu, dıştaki ul öğesini oluşturacak ve öğenin içine koyduğumuz tüm çocuklar, bunun içinde oluşturulacaktır.

 <Listem>
  <li>öğe1</li>
  <li>öğe2</li>
</Listem>

Bu, React bileşenleriyle tercih edilen modeldir. Çocuklara açık bir çocuk desteği olarak geçmek önerilmese de mümkündür:

 <MyList children={<li>item1</li><li>item2</li>} />

Yukarıdaki kullanım aslında bir hataya neden olacaktır, çünkü açık alt öğe olarak iletilen gibi JSX ifadelerinin tek bir kök öğeye sahip olması gerekir. Bu, çocukların bir parçaya sarılmasını gerektirir:

 <MyList children={<><li>item1</li><li>item2</li></>} />

İlk örnekte gösterildiği gibi, çocuklar doğrudan bileşene alt öğeler olarak geçirilir, bu nedenle bileşen, ifadenin kök öğesidir. Burada hiçbir parçaya veya başka bir çevreleyen öğeye ihtiyaç yoktur.

Bu esas olarak stilistik bir seçimdir/ children , ancak hem açık bir alt öğenin hem de alt öğelerin yanlışlıkla iletilmesini engeller:

 <MyList children={<><li>item1</li><li>item2</li></>}>
  <li>item3</li>
  <li>öğe4</li>
</Listem>

Bu durumda, alt öğeler ( item3 ve item4 ) görüntülenir, ancak item1 ve item2 gösterilmez. Bu kural, çocukların yalnızca alt JSX öğeleri olarak deyimsel bir şekilde geçirilmesini sağlar.

tepki ver/çocuklarla tehlike yok

React'in dangerouslySetInnerHTML özelliği, bir öğenin innerHTML özelliği olarak isteğe bağlı işaretlemenin ayarlanmasına izin verir. Uygulamanızı siteler arası komut dosyası çalıştırma (XSS) saldırısına maruz bırakabileceğinden bu genellikle önerilmez. Ancak, girdiye güvenebileceğinizi biliyorsanız ve kullanım durumu bunu gerektiriyorsa, bu yaklaşım gerekli hale gelebilir.

Prop, değeri ham HTML dizesi olan bir __html özelliğine sahip bir nesne bekler. Bu dize innerHTML olarak ayarlanacaktır.

Bu, mevcut herhangi bir alt içeriğin yerini aldığından, bunu bir children desteği ile birlikte kullanmak mantıklı değildir. Aslında, bunu yapmaya çalışırsanız, React bir hata verecektir. Yalnızca geliştirme modunda görünen bazı hataların aksine ( PropTypes doğrulama hataları gibi), bu hata uygulamanızı çökertecektir.

Bu kural aynı kuralı uygular. Çocuklarla dangerouslySetInnerHTML kullanılırsa, tiftik kuralı başarısız olur. Uygulama dağıtıldıktan sonra kullanıcılar tarafından rapor edilmektense, bu hataları linting sırasında veya derleme zamanında yakalamak çok daha iyidir!

tepki/jsx-no-bağlama

Bir React bileşeni her oluşturulduğunda, bunun bir performans maliyeti vardır. Çoğu zaman, belirli kalıplar veya uygulamalar, bir bileşenin kendisini gereksiz yere yeniden oluşturmasına neden olabilir. Bu davranışın birçok nedeni vardır ve bu kural bunlardan birinin önlenmesine yardımcı olur.

Bileşen içinde herhangi bir işlev tanımlandığında, her işlemede yeni bir işlev nesnesi olacaktır. Bu, bileşen yeniden oluşturulduğunda, pervanenin değiştirilmiş olarak kabul edildiği anlamına gelir. React.memo ile bile bileşen yeniden işlenecektir.

Alt bileşende, bu işlevi bağımlılık olarak alan herhangi bir useEffect çağrısı varsa, bu, etkinin yeniden çalışmasına neden olarak, tarayıcıyı donduracak sonsuz bir döngü potansiyeli yaratır.

Bu kural etkinleştirildiğinde, destek olarak geçirilen herhangi bir işlev işaretlenecektir.

Bunun ele alınmasının iki yolu vardır. İşlev, bileşenin içindeki başka bir şeye bağlı değilse, bileşenin dışına taşınabilir, burada her zaman aynı bellek referansı olacak yalnızca düz bir işlevdir. Bu, her seferinde aynı işlevin pervaneye iletilmesini sağlar.

İşlevin bir şekilde bileşene bağlı olduğu durumlarda, bunun için genel düzeltme, onu useCallback Hook ile not almaktır. İşlevde başvurulan tüm özelliklerin useCallback bağımlılık dizisine dahil edilmesi gerekir; bazen bu, değerlerin veya işlevlerin birden çok düzeyde hafızaya alınmasını gerektirir.

Bu biraz karmaşıklık ekler, ancak fazladan işlemeleri azaltmaya ve sonsuz döngüleri önlemeye yardımcı olma avantajına sahiptir.

toparlamak

Burada kapsanan kurallar, eslint-plugin-react eklentisi tarafından sağlananlardan sadece birkaçıdır. Bazı kurallar inatçı veya aşırı hevesli olabilir, ancak çoğu, onları daha az katı hale getirmek için yapılandırma seçeneklerine de sahiptir.

JSX ve erişilebilirlik uygulamalarına odaklanan çok yararlı başka bir ESLint eklentisi daha var:eslint-plugin-jsx-a11y . Bu eklentideki kurallar, iyi HTML erişilebilirlik uygulamalarının takip edildiğinden emin olmak için JSX işaretlemenizi kontrol eder.

Bu React ESLint eklentileri, özellikle React'te henüz yeniyseniz, yaygın tuzaklardan kaçınmanıza yardımcı olabilir. Diğer durumları kapsayacak şekilde kendi kurallarınızı ve eklentilerinizi bile yazabilirsiniz!

React için yazılan 12 temel ESLint kuralı ilk olarak LogRocket Blog'da göründü.

etiketlerETİKETLER
Üzgünüm, bu içerik için hiç etiket bulunmuyor.

Sıradaki içerik:

React için 12 temel ESLint kuralı