React Eğitimi: Bileşenler, Kancalar ve Performans

React eğitimimizin ilk bölümünde belirtildiği gibi, React'i kullanmaya başlamak nispeten kolaydır. Create React App (CRA) kullanarak başlayın, yeni bir proje başlatın ve geliştirmeye başlayın. Ne yazık ki zamanla, özellikle React'te yeniyseniz, kodunuzun bakımının oldukça zor olacağı bir duruma düşebilirsiniz. Bileşenler gereksiz yere büyüyebilir veya bileşen olabilecek ancak olmayan öğelerle sonuçlanabilir, böylece burada ve orada tekrarlayan kodlar yazabilirsiniz.

React geliştirme çözümlerinde düşünmeye başlayarak, React yolculuğunuza gerçekten başlamaya çalışmanız gereken yer burasıdır.

Yeni bir uygulamaya, daha sonra bir React uygulamasına dönüştürmeniz gereken yeni bir tasarıma yaklaştığınızda, önce çiziminizde hangi bileşenlerin olacağına, çizimi yönetmeyi kolaylaştırmak için nasıl ayırabileceğinize ve hangi öğelerin hangi öğelerin seçileceğine karar vermeye çalışın. tekrarlayan (veya en azından davranışları). “Gelecekte faydalı” olabilecek kod eklemekten kaçınmaya çalışın - cazip gelebilir, ancak bu gelecek asla gelmeyebilir ve birçok yapılandırılabilir seçeneğe sahip bu ekstra genel işlevi/bileşeni elinizde tutacaksınız.

Ayrıca, eğer bir bileşen 2-3 pencere yüksekliğinden daha uzunsa, belki daha sonra okumak daha kolay olacağı için (mümkünse) ayırmaya değer.

React'te Kontrollü ve Kontrolsüz Bileşenler

Çoğu uygulamada, girdiye ve kullanıcılarla bir şeyler yazmalarına, bir dosya yüklemelerine, bir alan seçmelerine vb. izin veren bir tür etkileşime ihtiyaç vardır. React, kullanıcı etkileşimini iki farklı şekilde ele alır: kontrollü ve kontrolsüz bileşenler.

Kontrollü bileşenlerin değeri, adından da anlaşılacağı gibi, kullanıcı ile etkileşime giren öğeye bir değer sağlayarak React tarafından kontrol edilirken, kontrol edilmeyen öğeler bir değer özelliği almaz. Bu sayede, Tepki durumu olan tek bir gerçek kaynağımız var, bu nedenle ekranda gördüklerimiz ile şu anda durumumuzda sahip olduklarımız arasında bir uyumsuzluk yok. Geliştiricinin, durumunu değiştirecek bir formla kullanıcı etkileşimine yanıt verecek bir işlevi geçmesi gerekir.

 class ControlledInput extends React.Component { state = { value: "" }; onChange = (e) => this.setState({ value: e.target.value }); render() { return ( <input value={this.state.value} onChange={this.onChange}/> ); } }

Kontrolsüz React bileşenlerinde değerin nasıl değiştiği ile ilgilenmiyoruz ancak tam değeri bilmek istiyorsak ref üzerinden basitçe erişiyoruz.

 class UncontrolledInput extends React.Component { input = React.createRef(); getValue = () => { console.log(this.input.current.value); }; render() { return ( <input ref={this.input}/> ); } }

Peki hangisi ne zaman kullanılmalı? Kontrollü bileşenlerin çoğu durumda gidilecek yol olduğunu söyleyebilirim, ancak bazı istisnalar var. Örneğin, değeri salt okunur olduğundan ve program aracılığıyla ayarlanamadığından (kullanıcı etkileşimi gereklidir) React'te kontrolsüz bileşenleri kullanmanız gereken bir durum file türü girişidir. Ayrıca, kontrollü bileşenleri okuması ve üzerinde çalışması daha kolay buluyorum. Kontrol edilen bileşenler için doğrulama yapmak yeniden işlemeye dayanır, durum değiştirilebilir ve girdide bir sorun olduğunu kolayca belirtebiliriz (örn. format veya boş olma).

Referanslar

16.8'de kancalar görünene kadar sınıf bileşenlerinde bulunan özel bir özellik olan refs daha önce bahsetmiştik.

Referanslar, geliştiriciye referans yoluyla bir React bileşenine veya DOM öğesine (ref eklediğimiz türe bağlı olarak) erişim verebilir. Kodun okunmasını biraz zorlaştırdıkları ve yukarıdan aşağıya veri akışını bozdukları için, bunlardan kaçınmaya çalışmak ve bunları yalnızca olması gereken senaryolarda kullanmak iyi bir uygulama olarak kabul edilir. Ancak, özellikle DOM öğelerinde (örneğin, odağı programlı olarak değiştirme) gerekli oldukları durumlar vardır. Bir React bileşen öğesine eklerken, bahsettiğiniz bileşen içindeki yöntemleri özgürce kullanabilirsiniz. Yine de, bununla başa çıkmanın daha iyi yolları olduğu için bu uygulamadan kaçınılmalıdır (örneğin, durumu yukarı kaldırma ve işlevleri ana bileşenlere taşıma).

Referansların ayrıca gerçekleştirilebilecekleri üç farklı yolu vardır:

• Bir dize değişmezi kullanma (eski ve bundan kaçınılmalıdır),
• ref özniteliğinde ayarlanan bir geri arama işlevini kullanarak,
• React.createRef() olarak ref oluşturarak ve onu bir sınıf özelliğine bağlayarak ve bunun üzerinden erişerek (referansların componentDidMount yaşam döngüsünden sağlanacağını unutmayın).

Son olarak, referansların aktarılmadığı durumlar ve mevcut bileşenden daha derin bir referans öğesine erişmek istediğiniz zamanlar vardır (örneğin, bir <input> DOM öğesine sahip bir <Button> bileşeniniz var ve şu anda bir <Row> bileşenindedir ve DOM odak işlevini girmek için erişime sahip olmak istediğiniz satır bileşeninden forwardRef 'i kullanacağınız yer burasıdır).

Referansın aktarılmadığı bir durum, bir bileşende daha yüksek dereceli bir bileşenin kullanılmasıdır - ref bir prop ( key 'e benzer) DEĞİL olduğundan, nedeni oldukça anlaşılabilir, bu nedenle aktarılmıyor, bu yüzden olacak tarafından sarılmış bileşen yerine HOC atıfta bulunmak. Böyle bir durumda, props ve React.forwardRef argüman olarak alan, daha sonra prop atanabilen ve erişmek istediğimiz bileşene aktarılan React.forwardRef'i kullanabiliriz.

 function withNewReference(Component) { class Hoc extends React.Component { render() { const {forwardedRef, ...props} = this.props; return <Component ref={forwardedRef} {...props}/>; } } return React.forwardRef((props, ref) => { return <Hoc {...props} forwardedRef={ref} />; }); }

Hata Sınırları

İşler ne kadar karmaşık hale gelirse, bir şeylerin yanlış gitme olasılığı o kadar yüksek olur. Bu nedenle hata sınırları React'in bir parçasıdır. Peki nasıl çalışıyorlar?

Bir şeyler ters giderse ve ebeveyni olarak hata sınırı yoksa, tüm React uygulamasının başarısız olmasına neden olur. Kullanıcıları yanlış yönlendirmek ve yanlış bilgiler göstermektense bilgileri göstermemek daha iyidir, ancak bu, tüm uygulamayı çökertmeniz ve beyaz bir ekran göstermeniz gerektiği anlamına gelmez. Hata sınırlarıyla, kullanabileceğiniz ek bir esneklik derecesine sahipsiniz. Birini uygulamanın tamamında kullanabilir ve bir hata mesajı görüntüleyebilir veya bazı widget'larda kullanıp bunları görüntülemeyebilir veya bu widget'lar yerine az miktarda bilgi görüntüleyebilirsiniz.

Bazı olayları veya çağrıları işlemek için yazdığınız zorunlu kod yerine yalnızca bildirim koduyla ilgili sorunlarla ilgili olduğunu unutmayın. Bunlar için yine de normal dene/yakala yaklaşımını kullanmalısınız.

Hata sınırları aynı zamanda kullandığınız Error Logger'a ( componentDidCatch yaşam döngüsü yönteminde) bilgi gönderebileceğiniz bir yerdir.

 class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logToErrorLogger(error, info); } render() { if (this.state.hasError) { return <div>Help, something went wrong.</div>; } return this.props.children; } }

Üst Düzey Bileşenler

Yüksek Dereceli Bileşenlerden (HOC) genellikle React'te bahsedilir ve muhtemelen kullanacağınız (veya zaten kullanmış olduğunuz) çok popüler bir kalıptır. HOC'lere aşina iseniz, muhtemelen birçok kitaplıkta withNavigation, connect, withRouter .

HOC'ler yalnızca bir bileşeni argüman olarak alan ve HOC sarmalayıcısı olmayana kıyasla genişletilmiş yeteneklere sahip yeni bir bileşen döndüren işlevlerdir. Bu sayede, bileşenlerinizi geliştirebilecek bazı kolay genişletilebilir işlevler elde edebilirsiniz (örneğin, navigasyona erişim). HOC'ler ayrıca sahip olduklarımıza bağlı olarak birkaç form alabilir, her zaman gerekli olan tek argüman bir bileşen olmak zorundadır, ancak ekstra argümanlar alabilir - bazı seçenekler veya connect 'deki gibi, önce daha sonra bir fonksiyon döndüren konfigürasyonlara sahip bir fonksiyonu çağırırsınız. hangi bir argüman bileşeni alır ve HOC döndürür.

Ekleyebileceğiniz ve kaçınmanız gereken birkaç şey var:

• Sarmalayıcı HOC işleviniz için bir görünen ad ekleyin (böylece HOC bileşeni görünen adınızı değiştirerek bunun aslında bir HOC olduğunu bilirsiniz).
• HOC'yi bir oluşturma yönteminde kullanmayın; her zaman yeniden monte etmek ve mevcut durumunu kaybetmek nedeniyle orada yeni bir HOC bileşeni oluşturmak yerine, içinde zaten gelişmiş bir bileşen kullanıyor olmalısınız.
• Statik yöntemler kopyalanmaz, bu nedenle yeni oluşturduğunuz HOC'nizin içinde bazı statik yöntemlere sahip olmak istiyorsanız, bunları kendiniz kopyalamanız gerekir.
• Bahsedilen Ref'ler geçilmedi, bu nedenle bu tür sorunları çözmek için daha önce belirtildiği gibi React.forwardRef kullanın.

 export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log("Very Important Function"); }; render() { return ( <Component {...this.props} importantFunction={this.importantFunction} /> ); } }; }

stil

Stil, mutlaka React'in kendisiyle ilgili değildir, ancak birkaç nedenden dolayı bahsetmeye değer.

Her şeyden önce, normal CSS/satır içi stilleri burada normal olarak uygulanır ve className özniteliğine CSS'den sınıf adları ekleyebilirsiniz ve doğru şekilde çalışacaktır. Satır içi stil, normal HTML stilinden biraz farklıdır. Dize, stiller ile değil, her biri için doğru değerlere sahip nesnelerle aktarılıyor. Stil nitelikleri de camelCased'dir, bu nedenle border-radius borderRadius olur ve bu böyle devam eder.

React, yalnızca name.modules.css değil, yakın zamanda CRA'ya entegre edilen CSS modülleri gibi birkaç çözümü popüler hale getirmiş görünüyor. , örneğin, WebStorm ayrıca bunun için hangi adların kullanılabilir olduğunu söyleyen Otomatik Tamamlama özelliğine sahiptir).

React'te de popüler olan başka bir çözüm, CSS-in-JS'dir (örneğin, emotion kitaplığı). Tekrar belirtmek gerekirse, CSS modülleri ve duygu (veya genel olarak CSS-in-JS) React ile sınırlı değildir .

Tepkideki Kancalar

Kancalar , muhtemelen yeniden yazma işleminden bu yana React'e en hevesle beklenen eklemedir. Ürün yutturmaca kadar yaşıyor mu? Benim açımdan, evet, gerçekten harika bir özellik oldukları için. Bunlar esasen yeni fırsatlar açan işlevlerdir, örneğin:

• Yalnızca yerel bir duruma veya referansa sahip olamadığımız için kullandığımız birçok class bileşeninin kaldırılmasına izin verir, böylece bir bileşenin kodunun okunması daha kolay görünür.
• Aynı efekt için daha az kod kullanmanızı sağlar.
• Örneğin, tepki testi kitaplığını kullanarak, işlevleri düşünmeyi ve test etmeyi çok daha kolay hale getirir.
• Ayrıca parametreler alabilir ve birinin sonucu başka bir kanca tarafından kolayca kullanılabilir (örneğin, setState içinde useState useEffect ).
• Küçültücüler için biraz daha sorunlu olma eğiliminde olan sınıflardan çok daha iyi küçültür.
• HOC'leri kaldırabilir ve uygulamanızda, başkalarını çözmek için tasarlanmış olmasına rağmen yeni sorunlar ortaya çıkaran sahne kalıpları oluşturabilir.
• Herhangi bir yetenekli React geliştiricisi tarafından özel olarak oluşturulabilir.

Varsayılan olarak dahil edilen birkaç React kancası vardır. Üç temel olanlar useState , useEffect ve useContext . Ayrıca birkaç ek var, örneğin useRef ve useMemo , ancak şimdilik temellere odaklanacağız.

useState bir göz atalım ve onu basit bir sayaç örneği oluşturmak için kullanalım. O nasıl çalışır? Temel olarak, tüm yapı gerçekten basittir ve şöyle görünür:

 export function Counter() { const [counter, setCounter] = React.useState(0); return ( <div> {counter} <button onClick={() => setCounter(counter + 1)}>+</button> </div> ); };

initialState (değer) ile çağrılır ve iki elemanlı bir dizi döndürür. Dizi yok etme ataması sayesinde değişkenleri bu elemanlara hemen atayabiliriz. Birincisi her zaman güncellemelerden sonraki son durumdur, diğeri ise değeri güncellemek için kullanacağımız bir fonksiyondur. Oldukça kolay görünüyor, değil mi?

Ayrıca, bu tür bileşenlere önceden durumsuz işlevsel bileşenler denmesi nedeniyle, yukarıda gösterildiği gibi bir duruma sahip olabileceklerinden böyle bir ad artık uygun değildir. Bu nedenle, sınıf bileşenleri ve işlev bileşenleri adları, en azından 16.8.0'dan itibaren gerçekte yaptıklarıyla daha uyumlu görünmektedir.

Güncelleme işlevi (bizim durumumuzda setCounter ), önceki değeri aşağıdaki biçimde bir argüman olarak alacak bir işlev olarak da kullanılabilir:

 <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button>

Ancak, sığ bir birleştirme yapan this.setState sınıfı bileşeninin aksine, işlevi (bizim durumumuzda setCounter ) ayarlamak bunun yerine tüm durumu geçersiz kılar.

Ayrıca, initialState yalnızca düz bir değer değil, bir işlev de olabilir. Bunun kendi faydaları vardır, çünkü bu işlev yalnızca bileşenin ilk oluşturma işlemi sırasında çalıştırılır ve bundan sonra artık çağrılmaz.

 const [counter, setCounter] = useState(() => calculateComplexInitialValue());

Son olarak, setCounter mevcut durumda ( counter ) aynı anda sahip olduğumuz değerle tam olarak aynı olacak şekilde kullanacaksak, bileşen yeniden oluşturulmayacaktır.

Öte yandan useEffect , abonelikler, API çağrıları, zamanlayıcılar veya yararlı bulabileceğimiz hemen hemen her şey gibi işlevsel bileşenimize yan etkiler eklemekle ilgilidir. useEffect geçireceğimiz herhangi bir işlev, oluşturma işleminden sonra çalıştırılacaktır ve işlevin ikinci argümanı olarak hangi özelliklerin değişikliklerinin yeniden çalıştırılacağına ilişkin bir sınırlama eklemediğimiz sürece, her oluşturmadan sonra bunu yapacaktır. Eğer onu sadece mount'ta çalıştırmak ve unmount'ta temizlemek istiyorsak, içine boş bir dizi geçirmemiz yeterli.

 const fetchApi = async () => { const value = await fetch("https://jsonplaceholder.typicode.com/todos/1"); console.log(await value.json()); }; export function Counter() { const [counter, setCounter] = useState(0); useEffect(() => { fetchApi(); }, []); return ( <div> {counter} <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button> </div> ); };

Yukarıdaki kod, ikinci bir argüman olarak boş bir dizi nedeniyle yalnızca bir kez çalıştırılacaktır. Temel olarak, böyle bir durumda componentDidMount gibi bir şeydir, ancak biraz sonra patlar. Tarayıcı boyamadan önce çağrılan benzer bir kancaya sahip olmak istiyorsanız, useLayoutEffect kullanın, ancak bu güncellemeler useEffect aksine eşzamanlı olarak uygulanacaktır.

Hangi bağlama erişmek istediğimizi ( createContext işlevi tarafından döndürülen bir nesne) sağladığı ve karşılığında bize bu bağlamın değerini sağladığı için useContext, anlaşılması en kolay useContext gibi görünüyor.

 const context = useContext(Context);

Son olarak, kendi kancanızı yazmak için aşağıdakine benzer bir şey yazabilirsiniz:

 function useWindowWidth() { let [windowWidth, setWindowWidth] = useState(window.innerWidth); function handleResize() { setWindowWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); return windowWidth; }

Temel olarak, başlangıç ​​değeri pencere genişliği olarak atadığımız normal useState kancasını kullanıyoruz. Ardından useEffect, , her pencere yeniden boyutlandırmasında handleResize tetikleyecek bir dinleyici ekliyoruz. Bileşenin bağlantısının kaldırılmasından sonra da temizleriz ( useEffect içindeki dönüşe bakın). Kolay?

Not: Tüm kancalarda kelime kullanımı önemlidir. React'in kötü bir şey yapmadığınızı kontrol etmesine izin verdiği için kullanılır, örneğin normal JS işlevlerinden çağrı kancaları.

Kontrol Tipleri

Flow ve TypeScript bir seçenek olmadan önce React'in kendi sahne denetimi vardı.

PropTypes, bir React bileşeni tarafından alınan özelliklerin (props) olup olmadığını ve sahip olduklarımız ile uyumlu olup olmadığını kontrol eder. Farklı bir durum oluştuğunda (örneğin dizi yerine nesne) konsolda bir uyarı alırız. PropType'ların performans üzerindeki etkileri ve yukarıda belirtilen konsol uyarısı nedeniyle yalnızca geliştirme modunda kontrol edildiğini unutmamak önemlidir.

React 15.5'ten itibaren PropType'lar ayrı olarak kurulması gereken farklı bir pakettedir. Bunlar, propTypes (sürpriz) adlı statik bir özellikte özellikler boyunca bildirilir ve bunları, özellikler tanımsızsa (tek durum tanımsız ise) kullanılan defaultProps ile birleştirir. DefaultProps, PropTypes ile ilgili değildir, ancak PropTypes nedeniyle ortaya çıkabilecek bazı uyarıları çözebilirler.

Diğer iki seçenek Flow ve TypeScript'tir ve günümüzde çok daha popülerdirler (özellikle TypeScript).

• TypeScript , Microsoft tarafından geliştirilen, bir uygulama çalışmaya başlamadan önce hataları kontrol edebilen ve geliştirme için üstün otomatik tamamlama işlevselliği sağlayan, JavaScript'in yazılı bir üst kümesidir. Ayrıca yeniden düzenlemeyi büyük ölçüde geliştirir. Yazılı diller konusunda kapsamlı deneyime sahip Microsoft desteği nedeniyle, oldukça güvenli bir seçimdir.
• Flow , TypeScript'ten farklı olarak bir dil değildir. JavaScript için statik bir tür denetleyicisidir, bu nedenle bir dilden çok JavaScript'e eklediğiniz bir araca benzer. Flow'un arkasındaki fikir, TypeScript'in sunduğuna oldukça benzer. Kodu çalıştırmadan önce herhangi bir hata olması olasılığını azaltmak için türler eklemenize olanak tanır. TypeScript gibi, Flow da artık baştan itibaren CRA'da (Create React App) destekleniyor.

Şahsen, özellikle Flow ile biraz daha yavaş görünen otomatik tamamlamada TypeScript'i daha hızlı (neredeyse anlık) buluyorum. Kişisel olarak kullandığım WebStorm gibi IDE'lerin Flow ile entegrasyon için bir CLI kullandığını belirtmekte fayda var. Bununla birlikte, tip kontrolünü başlatmak için dosyanın başına // @flow eklediğiniz dosyalara isteğe bağlı kullanımı entegre etmek daha da kolay görünüyor. Ayrıca, söyleyebileceğim kadarıyla, sonunda TypeScript Flow'a karşı savaşı kazandı - şimdi çok daha popüler ve en popüler kitaplıklardan bazıları Flow'dan TypeScript'e yeniden düzenleniyor.

Resmi belgelerde de bahsedilen, Reason (Facebook tarafından geliştirildi ve React topluluğunda popülerlik kazanıyor), Kotlin (JetBrains tarafından geliştirilen bir dil) ve daha fazlası gibi birkaç seçenek daha var.

Açıkçası, ön uç geliştiriciler için en kolay yaklaşım, Kotlin veya F#'a geçmek yerine Flow ve TypeScript'i kullanmaya başlamak olacaktır. Ancak, ön uca geçiş yapan arka uç geliştiriciler için, bunları kullanmaya başlamak aslında daha kolay olabilir.

Üretim ve Tepki Performansı

Üretim modu için yapmanız gereken en temel ve bariz değişiklik, DefinePlugin için “üretim”e geçmek ve UglifyJsPlugin durumunda UglifyJsPlugin'i eklemektir. CRA söz konusu olduğunda, npm run build ( react-scripts build çalıştıracak) kullanmak kadar basittir. Brunch gibi diğer oluşturma araçlarını kullanabileceğiniz için Webpack ve CRA'nın tek seçenek olmadığını unutmayın. Bu, ister resmi React belgeleri isterse belirli bir araç için belgeler olsun, genellikle resmi belgelerde ele alınır. Modun doğru şekilde ayarlandığından emin olmak için, ne tür bir yapı kullandığınızın (üretim ve geliştirme) hakkında size bir gösterge verecek olan React Developer Tools'u kullanabilirsiniz. Yukarıda bahsedilen adımlar, uygulamanızın React'ten gelen kontroller ve uyarılar olmadan çalışmasını sağlayacak ve paketin kendisi de en aza indirilecektir.

React uygulamanız için yapabileceğiniz birkaç şey daha var. Oluşturulan JS dosyasıyla ne yaparsınız? Boyut nispeten küçükse yalnızca "bundle.js" ile başlayabilir veya "satıcı + paket" veya belki "satıcı + gerekli en küçük parça + gerektiğinde öğeleri içe aktar" gibi bir şey yapabilirsiniz. Bu, çok büyük bir uygulamayla uğraşırken kullanışlıdır ve en başta her şeyi içe aktarmanız gerekmez. Ana pakette kullanılmayan bazı JavaScript kodlarını gruplamanın paket boyutunu artıracağını ve uygulamanın en başında daha yavaş yüklenmesini sağlayacağını unutmayın.

Satıcı paketleri, kitaplıkların sürümlerini uzun süre değişmeyebileceklerini (eğer varsa) fark ettikten sonra dondurmayı planlıyorsanız yararlı olabilir. Ayrıca, daha büyük dosyalar gziplemede daha iyidir, bu nedenle ayırmadan elde ettiğiniz fayda bazen buna değmeyebilir. Dosya boyutuna bağlıdır ve bazen sadece kendiniz denemeniz gerekir.

Kod Bölme

Kod bölme burada önerilenden daha fazla şekilde görünebilir, ancak şimdi CRA ve React'in kendisinde nelere sahip olduğumuza odaklanalım. Temel olarak, kodu farklı parçalara bölmek için, Webpack sayesinde çalışan import import() kullanabiliriz ( import'un kendisi şu anda Aşama 3'te bir tekliftir, dolayısıyla henüz dil standardının bir parçası değildir). Webpack import öğesini her gördüğünde, bu aşamada kod bölmeye başlaması gerektiğini ve onu ana pakete (içeri aktarmanın içindeki kod) dahil edemeyeceğini bilecektir.

Şimdi onu, import() gerektiren React.lazy() ile o yerde oluşturulması gereken bileşeni içeren bir dosya yolu ile bağlayabiliriz. Ardından, içe aktarılan bileşen yüklenene kadar o yerde farklı bir bileşen gösterecek olan React.suspense() kullanabiliriz. Biri merak edebilir; tek bir bileşen ithal ediyorsak, neden buna ihtiyacımız olsun ki?

React.lazy() , import() 'u gösterdiğimiz bileşeni göstereceğinden durum tam olarak böyle değil, ancak import() bu tek bileşenden daha büyük bir yığın getirebilir. Örneğin, söz konusu bileşenin yedekte başka kitaplıkları, daha fazla kodu vb. olabilir, bu nedenle tek bir dosya gerekli değildir—birlikte paketlenmiş çok daha fazla dosya olabilir. Son olarak, bunların hepsini ErrorBoundary (kodu hata sınırları ile ilgili bölümümüzde bulabilirsiniz), bu, içe aktarmak istediğimiz bileşende bir şey başarısız olursa (örneğin, bir ağ hatası varsa) bir geri dönüş işlevi görecektir.

 import ErrorBoundary from './ErrorBoundary'; const ComponentOne = React.lazy(() => import('./ComponentOne')); function MyComponent() { return ( <ErrorBoundary> <React.Suspense fallback={<div>Loading...</div>}> <ComponentOne/> </React.Suspense> </ErrorBoundary> ); }

Bu basit bir örnek, ancak açıkçası daha fazlasını yapabilirsiniz. Dinamik rota bölme için import ve React.lazy kullanabilirsiniz (örneğin, admin ve normal kullanıcı veya sadece çok şey getiren gerçekten büyük yollar). React.lazy şu anda yalnızca varsayılan dışa aktarmayı desteklediğini ve sunucu tarafı oluşturmayı desteklemediğini unutmayın.

Tepki Kodu Performansı

Performansla ilgili olarak, React uygulamanız gecikmeli davranıyorsa, sorunu çözmenize yardımcı olabilecek iki araç vardır.

İlki, her bir bileşende (örneğin, bağlama, güncelleme) ne olduğunu size söyleyen Chrome Performans Sekmesidir. Bu sayede, hangi bileşenin performans sorunları gösterdiğini belirleyebilmeli ve ardından onu optimize edebilmelisiniz.

Diğer seçenek, React 16.5+ sürümünde kullanıma sunulan DevTools Profiler'ı kullanmaktır ve mustComponentUpdate (veya bu öğreticinin bir bölümünde açıklanan PureComponent) işbirliğiyle bazı kritik bileşenlerin performansını iyileştirebiliriz.

Açıktır ki, bazı olayların geri dönmesi (örneğin, kaydırma), animasyonlara karşı dikkatli olmak (yüksekliği değiştirmek ve onu canlandırmak yerine dönüştürmeyi kullanmak) vb. gibi web için temel en iyi uygulamaları kullanmak en uygunudur. En iyi uygulamaları kullanmak, özellikle React'i yeni yeni öğreniyorsanız, kolayca gözden kaçabilir.

2019 ve Ötesinde Tepkinin Durumu

React'in geleceğini kişisel olarak tartışacak olsaydık, çok endişelenmezdim. Benim açımdan, React 2019 ve sonrasında tahtını korumakta zorluk çekmeyecek.

React, geniş bir kitle tarafından desteklenen, o kadar güçlü bir duruşa sahip ki, tahttan indirmek zor olacak. React Topluluğu harika, fikirler tükenmiyor ve çekirdek ekip sürekli olarak React'i geliştirmek, yeni özellikler eklemek ve eski sorunları düzeltmek için çalışıyor. React ayrıca büyük bir şirket tarafından destekleniyor, ancak lisans sorunları ortadan kalktı - şu anda MIT lisanslı.

Evet, değiştirilmesi veya iyileştirilmesi beklenen birkaç şey var; örneğin, React'i biraz küçültmek (belirtilen önlemlerden biri sentetik olayları kaldırmaktır) veya className class. Tabii ki, görünüşte küçük olan bu değişiklikler bile tarayıcı uyumluluğunu etkileme gibi sorunlara neden olabilir. Kişisel olarak, WebComponent daha popüler hale geldiğinde ne olacağını merak ediyorum, çünkü React'in günümüzde sıklıkla kullanıldığı bazı şeyleri artırabilir. Bunların yerini alacaklarına inanmıyorum ama birbirlerini güzel bir şekilde tamamlayabileceklerine inanıyorum.

Kısa vadeye gelince, kancalar React'e geldi. Bu, React'te yeniden yazmanın gerçekleşmesinden bu yana muhtemelen en büyük değişiklik, çünkü bunlar birçok olasılık açacak ve daha fazla işlev bileşenini geliştirecek (ve şimdi gerçekten abartılıyorlar).

Son olarak, son zamanlarda yaptığım şey bu olduğu için React Native var. Benim için, son birkaç yılda çok fazla değişen harika bir teknoloji (tepki-yerel bağlantının olmaması muhtemelen çoğu insan için en büyük sorundu ve açıkçası birçok hata vardı). React Native, çekirdeğini yeniden yazmaktadır ve bu, React yeniden yazma işlemine benzer şekilde yapılmalıdır (hepsi dahilidir, geliştiriciler için hiçbir şey veya neredeyse hiçbir şey değiştirilmemelidir). Zaman uyumsuz oluşturma, yerel ve JavaScript arasında daha hızlı ve daha hafif bir köprü ve daha fazlası.

React ekosisteminde sabırsızlıkla beklenecek çok şey var, ancak kancalar (ve birisi cep telefonlarını seviyorsa React Native) güncellemeleri muhtemelen 2019'da göreceğimiz en önemli değişiklikler.