Както беше посочено в първата част от нашия урок за React , да започнете с React е относително лесно. Започнете с помощта на Create React App (CRA), създайте нов проект и започнете да се развивате. За съжаление, с течение на времето може да стигнете до ситуация, при която кодът ви ще стане доста труден за поддръжка, особено ако сте нов в React. Компонентите могат да станат ненужно големи или може да се окажете с елементи, които могат да бъдат компоненти, но не са, така че в крайна сметка можете да напишете повтарящ се код тук и там.

Това е мястото, където трябва да се опитате наистина да започнете вашето React пътешествие - като започнете да мислите Реагирайте решения за развитие .

Всеки път, когато се обърнете към ново приложение, нов дизайн, който по-късно трябва да преобразувате в приложение на React, първо се опитайте да решите кои компоненти ще бъдат във вашата скица, как можете да отделите скицата, за да ги улесните в управлението и кои елементи са повтарящи се (или поне тяхното поведение). Опитайте се да избягвате да добавяте код, който може да бъде „полезен в бъдеще“ - може да е примамливо, но това бъдеще може никога да не настъпи и ще запазите тази допълнителна обща функция / компонент, която има много конфигурируеми опции.

Също така, ако компонентът е по-дълъг от, да речем 2-3 височина на прозореца, може би си струва да се отдели (ако е възможно) - тъй като по-късно ще бъде по-лесно да го прочетете.

Контролирани срещу неконтролирани компоненти в React

В повечето приложения има нужда от въвеждане и някаква форма на взаимодействие с потребителите, което им позволява да напишат нещо, да качат файл, да изберат поле и т.н. React се занимава с взаимодействие с потребителя по два различни начина - контролирани и неконтролирано компоненти.

Стойността на контролираните компоненти, както подсказва името им, се контролира от React чрез предоставяне на стойност на елемента, който взаимодейства с потребителя, докато неконтролираните елементи не получават свойство стойност. Благодарение на това имаме един-единствен източник на истина, който се оказва състоянието на React, така че няма несъответствие между това, което виждаме на екрана, и това, което в момента имаме в нашето състояние. Разработчикът трябва да предаде функция, която ще реагира на взаимодействието на потребителя с формуляр, който ще промени състоянието му.

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

В неконтролираните компоненти на React не ни интересува как се променя стойността, но ако искаме да знаем точната стойност, просто имаме достъп до нея чрез ref.

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

И така, кое трябва да се използва кога? Бих казал, че контролираните компоненти са начинът, по който трябва да се работи в повечето случаи, но има някои изключения. Например, един случай, в който трябва да използвате неконтролирани компоненти в React, е file въведете тип, тъй като стойността му е само за четене и не може да бъде зададена програмно (изисква се взаимодействие с потребителя). Също така намирам контролираните компоненти по-лесни за четене и по-лесни за работа. Извършването на проверка за контролирани компоненти се основава на повторното изобразяване, състоянието може да бъде променено и можем лесно да посочим, че има нещо нередно с входа (например, форматиране или празно).

Реф

Вече споменахме refs, които са специална функция, която се предлагаше в компонентите на класа, докато куките се появиха в 16.8.

Refs могат да дадат на разработчика достъп до React компонент или DOM елемент (в зависимост от типа, към който прикачваме ref) чрез препратка. Счита се за добра практика да се опитвате да ги избягвате и да ги използвате само в задължителни сценарии, тъй като правят кода малко по-труден за четене и прекъсват потока от данни отгоре надолу. И все пак има случаи, когато те са необходими, особено върху DOM елементи (например, промяна на фокуса програмно). Когато се прикачвате към елемент на React компонент, можете свободно да използвате методи от този компонент, към който се отнасяте. Все пак тази практика трябва да се избягва, тъй като има по-добри начини за справяне с нея (напр. Повдигане на състоянието и преместване на функции към родителски компоненти).

как да проектирате за мобилни устройства

Препратките също имат три различни начина, по които могат да бъдат изпълнени:

• Използване на низ литерал (наследство и трябва да се избягва),
• Използвайки функция за обратно извикване, която се задава в атрибута ref,
• Чрез създаване на ref като React.createRef() и да го обвържете със свойство на клас и да го осъществите чрез него (имайте предвид, че препратките ще бъдат достъпни от жизнения цикъл на componentDidMount).

И накрая, има случаи, когато refs не се предават и моменти, когато искате да получите достъп до по-задълбочен референтен елемент от текущия компонент (например, имате acomponent, който има елемент insideDOM и в момента сте в acomponent и от реда компонент, който искате да имате достъп за въвеждане на функцията за фокусиране на DOM. Там бихте използвали forwardRef).

Един случай, когато препращането не се предава, е когато има компонент от по-висок ред се използва върху компонент - причината е напълно разбираема като ref НЕ е prop (подобно на key), така че не се предава, така че ще препраща към HOC вместо компонентът да бъде увит от него. В такъв случай можем да използваме React.forwardRef който приема реквизити и препратки като аргументи, които след това могат да бъдат присвоени на prop и се предава на компонента, до който искаме достъп.

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

Граници на грешки

Колкото по-сложни стават нещата, толкова по-голяма е вероятността нещо да се обърка. Ето защо граници на грешки са част от React. И така, как работят?

Ако нещо се обърка и като родител няма граница на грешка, това ще доведе до отказ на цялото приложение React. По-добре е да не показвате информация, вместо да заблуждавате потребителите и да показвате грешна информация, но това не означава непременно, че трябва да сривате цялото приложение и да показвате бял екран. С границите на грешките имате допълнителна степен на гъвкавост, която можете да използвате. Можете или да използвате такъв в цялото приложение и да покажете съобщение за грешка, или да го използвате в някои приспособления и просто да не ги показвате, или вместо това да покажете малко количество информация вместо тези приспособления.

Не забравяйте, че става въпрос само за проблеми с декларативен код, а не за императивен код, който пишете за обработка на някои събития или повиквания. За тях все пак трябва да използвате обикновения опитай да хванеш Приближаване.

Границите на грешките също са място, където можете да изпращате информация до Регистратор на грешки които използвате (в метода componentDidCatch жизнения цикъл).

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 Help, something went wrong. ; } return this.props.children; } }

Компоненти от по-висок ред

Компоненти от по-висок ред (HOC) често се споменават в React и са много популярен модел, който вероятно ще използвате (или вече сте го направили). Ако сте запознати с HOC, вероятно сте виждали withNavigation, connect, withRouter в много библиотеки.

HOC са просто функции, които приемат компонент като аргумент и ще върнат нов компонент с разширени възможности в сравнение с този без обвивката HOC. Благодарение на това можете да постигнете някои лесно разширяеми функции, които биха могли да подобрят вашите компоненти (напр. Достъп до навигация). HOC също могат да приемат няколко форми, извикани в зависимост от това, което имаме, като единственият аргумент, който винаги се изисква, е компонент, но може да вземе допълнителни аргументи - някои опции или като в connect, първо извиквате функция с конфигурации, които по-късно връща функция, която приема компонент на аргумент и връща HOC.

Има няколко неща, които можете да добавите и които трябва да избягвате:

• Добавете име на дисплей за вашата функция HOC на обвивката (за да знаете, че всъщност това е HOC, като промените името на дисплея на вашия HOC компонент).
• Не използвайте HOC вътре в метод за рендиране - вече трябва да използвате подобрен компонент вътре в него, вместо да създавате нов HOC компонент там, като го ремонтирате през цялото време и губите текущото си състояние.
• Статичните методи не се копират, така че ако искате да имате някои статични методи във вашия новосъздаден HOC, трябва да ги копирате върху себе си.
• Споменатото Реф не са предадени, така че използвайте React.forwardRef както бе споменато по-горе за решаване на такива въпроси.

export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log('Very Important Function'); }; render() { return ( ); } }; }

Стайлинг

Стилирането не е задължително свързано със самия React, но си струва да се спомене поради редица причини.

На първо място, обикновените CSS / вградени стилове се прилагат тук като нормални и можете просто да добавите имена на класове от CSS в атрибута className и това ще работи правилно. Вграденият стил е малко по-различен от обикновения HTML стил. Низът не се предава със стилове, а по-скоро обекти с правилни стойности за всеки. Атрибутите на стила също са camelCased, така че border-radius става borderRadius и така нататък.

React изглежда популяризира няколко решения, които станаха нещо обичайно не само в React, като CSS модули, които наскоро бяха интегрирани в CRA, където можете просто да импортирате name.modules.css и използвайте неговите класове като свойства, за да оформите вашия компонент (някои IDE, например WebStorm, също имат Autocomplete за това, което ви казва кои имена са налични).

Друго решение, което също е популярно в React, е CSS-in-JS (например emotion библиотека). Само за да отбележа отново, CSS модулите и емоциите (или CSS-в-JS като цяло) са не се ограничава да реагираш.

Куки в React

Куки са напълно вероятно най-очакваното допълнение към React след пренаписването. Продуктът отговаря ли на хайпа? От моя гледна точка да, тъй като те наистина са страхотна характеристика. Те по същество са функции, които отварят нови възможности, като например:

• Позволява премахването на много class компоненти, които използвахме само защото не можехме да имаме, напр. локално състояние или реф., така че кодът за компонент изглежда по-лесен за четене.
• Позволява ви да използвате по-малко код за същия ефект.
• Улеснява мисленето и тестването на функциите, например с помощта на библиотека за реакция-тестване .
• Може също да приема параметри и резултатът от един може лесно да се използва от друга кука (например setState от useState в useEffect).
• Умалява по-добре от класовете, които са малко по-проблематични за минифайерите.
• Може да премахнете HOCs и да изобразите шаблони за реквизит във вашето приложение, което създаде нови проблеми, въпреки че е проектирано да решава други.
• Способни да бъдат изработени по поръчка от всеки квалифициран React разработчик .

Има няколко куки React, които са включени по подразбиране. Трите основни са useState, useEffect и useContext. Има и няколко допълнителни, например useRef и useMemo, но засега ще се съсредоточим върху основите.

Нека да разгледаме useState и да го използваме, за да създадем пример за ясен брояч. Как работи? Е, като цяло, цялата конструкция е наистина ясна и изглежда така:

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

Извиква се с initialState (стойност) и връща масив с два елемента с него. Благодарение на заданието за деструктуриране на масиви, ние можем веднага да присвоим променливите на тези елементи. Първото винаги е последното състояние след актуализации, докато другото е функция, която ще използваме за актуализиране на стойността. Изглежда доста лесно, нали?

Също така, поради факта, че такива компоненти са били наричани функционални компоненти без гражданство, такова име вече не е подходящо, тъй като те могат да имат състояние, както е показано по-горе. Оттук и имената клас компоненти и функционални компоненти изглежда повече отговарят на това, което всъщност правят, поне от 16.8.0.

Функцията за актуализация (в нашия случай setCounter), също може да се използва като функция, която ще приеме предишната стойност като аргумент в следната форма:

setCounter(prevCounter => prevCounter + 1)}>+ setCounter(prevCounter => prevCounter - 1)}>-

Въпреки това, за разлика от this.setState class компонент, който правеше плитко сливане, настройването на функцията (setCounter в нашия случай) замества вместо това цялото състояние.

В допълнение, initialState може да бъде и функция, а не само обикновена стойност. Това има свои собствени предимства, тъй като тази функция ще се изпълнява само по време на първоначалното изобразяване на компонента и след това вече няма да се извиква.

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

И накрая, ако ще използваме setCounter с точно същата стойност, която имахме в същия момент в текущото състояние (counter), след това компонент няма да препредаване.

От друга страна, useEffect е за добавяне на странични ефекти към нашия функционален компонент, независимо дали става въпрос за абонаменти, API извиквания, таймери или просто за всичко, което може да сметнем за полезно. Всяка функция, която ще предадем на useEffect ще се изпълнява след изобразяване и ще го прави след всяко изобразяване, освен ако не добавим ограничение относно това какви промени трябва да бъдат повторени като втори аргумент на функцията. Ако искаме да го стартираме само при монтиране и почистване при демонтаж, тогава просто трябва да предадем празен масив в него.

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 ( {counter} setCounter(prevCounter => prevCounter + 1)}>+ setCounter(prevCounter => prevCounter - 1)}>- ); };

Горният код ще се изпълни само веднъж поради празен масив като втори аргумент. По принцип това е нещо като componentDidMount в такъв случай, но се задейства малко по-късно. Ако искате да имате подобна кука, която се извиква преди боядисване на браузъра, използвайте useLayoutEffect, но тези актуализации ще се прилагат синхронно, за разлика от useEffect.

useContext изглежда най-лесно за разбиране, тъй като човек предоставя до кой контекст искаме да получим достъп (обект, който е върнат от функцията createContext), а в замяна ни предоставя стойността за този контекст.

const context = useContext(Context);

И накрая, за да напишете своя собствена кука, можете просто да напишете нещо като следното:

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; }

По принцип използваме обикновения useState кука, за която задаваме като начална стойност ширина на прозореца. Тогава в useEffect, добавяме слушател, който ще задейства handleResize на всеки прозорец преоразмерете. Също така изчистваме след като компонентът ще бъде демонтиран (вижте връщането в useEffect). Лесно?

Забележка: Думата използване във всички куки е важно. Използва се, защото позволява на React да проверява дали не правите нещо лошо, например да извиквате куки от обикновени JS функции.

научете как да използвате bootstrap

Проверка на типовете

React имаше собствена проверка на реквизита, преди Flow и TypeScript да бяха опция.

PropTypes проверява дали свойствата (props), получени от React компонент, и проверява дали са в съответствие с това, което имаме. Когато възникне различна ситуация (например обект вместо масив), ще получим предупреждение в конзолата. Важно е да се отбележи, че PropTypes се проверяват само в режим на разработка поради тяхното въздействие върху производителността и гореспоменатото предупреждение на конзолата.

От React 15.5 PropTypes са в различен пакет, който трябва да се инсталира отделно. Те се декларират по свойства в статично свойство, наречено propTypes (изненада), комбинирайки ги с defaultProps които се използват, ако свойствата са недефинирани ( неопределено е единственият случай). DefaultProps не са свързани с PropTypes, но те могат да разрешат някои предупреждения, които могат да се появят поради PropTypes.

Другите две опции са Flow и TypeScript и в днешно време са много по-популярни (особено TypeScript).

• TypeScript е типизиран супер набор от JavaScript, разработен от Microsoft, който може да проверява грешките, преди дадено приложение дори да се изпълнява, и осигурява превъзходна функционалност за автоматично довършване за разработка. Също така значително подобрява рефакторинга. Поради поддръжката на Microsoft, която има богат опит с типизирани езици, това също е доста безопасен избор.
• Поток не е език, за разлика от TypeScript. Това е проверка на статичен тип за JavaScript, така че е по-скоро подобен на инструмент, който включвате в JavaScript, отколкото на език. Цялата идея зад Flow е доста подобна на това, което TypeScript предлага. Тя ви позволява да добавяте типове, така че е по-малко вероятно да имате грешки, преди да стартирате кода. Подобно на TypeScript, Flow вече се поддържа в CRA (Create React App) от самото начало.

Лично аз намирам TypeScript по-бързо (практически мигновено), особено при автодовършване, което изглежда малко по-бавно с Flow. Струва си да се отбележи, че IDE като WebStorm, които аз лично използвам, използват CLI за интеграция с Flow. Изглежда обаче още по-лесно да се интегрира използването по избор във файлове, където просто добавяте // @flow в началото на файла, за да започне проверка на типа. Също така, от това, което мога да кажа, изглежда, че TypeScript спечели битката срещу Flow в крайна сметка - сега е много по-популярен и някои от най-популярните библиотеки се рефакторират от Flow към TypeScript.

Има още няколко опции, споменати също в официалната документация, като Reason (разработен от Facebook и набиращ популярност в общността React), Kotlin (език, разработен от JetBrains) и др.

Очевидно е, че за разработчиците от предния край най-лесният подход би бил да влязат и да започнат да използват Flow и TypeScript, вместо да преминат към Kotlin или F #. Въпреки това, за back-end разработчиците, които преминават към front-end, всъщност може да е по-лесно да започнете.

Производство и реагиране

Най-основната и очевидна промяна, която трябва да направите за производствен режим, е да преминете към „производство“ за DefinePlugin и добавете UglifyJsPlugin в случая с Webpack. В случая на CRA това е толкова просто, колкото използването на npm run build (което ще работи react-scripts build). Имайте предвид, че Webpack и CRA не са единствените опции, тъй като можете да използвате други инструменти за изграждане като Brunch. Това обикновено се покрива от официална документация, било то официална документация на React или документация за конкретен инструмент. За да сте сигурни, че режимът е зададен правилно, можете да използвате React Developer Tools , което ще ви даде индикация какъв тип компилация използвате (производство срещу разработка). Гореспоменатите стъпки ще направят приложението ви да се изпълнява без проверки и предупреждения, идващи от React, а самият пакет също ще бъде сведен до минимум.

Има още няколко неща, които можете да направите за вашето приложение React. Какво правите с JS файла, който е изграден? Можете да започнете само с „bundle.js“, ако размерът е относително малък, или може да направите нещо като „доставчик + пакет“ или може би „доставчик + най-малката необходима част + да импортирате неща, когато са необходими“. Това е полезно, когато имате работа с много голямо приложение и не е нужно да импортирате всичко в самото начало. Имайте предвид, че групирането на някакъв код на JavaScript в основния пакет, който дори не се използва, просто ще увеличи размера на пакета и ще направи зареждането на приложението по-бавно в самото начало.

Пакетите от доставчици могат да бъдат полезни, ако планирате да замразите версиите на библиотеките, след като осъзнаете, че те може да не се променят дълго време (ако изобщо изобщо). Освен това по-големите файлове са по-добри при gzipping, така че ползата, която получавате от разделянето, понякога може да не си заслужава. Това зависи от размера на файла и понякога просто ще трябва да опитате сами.

Разделяне на кода

Разделянето на кода може да се появи по повече начини, отколкото е предложено тук, но нека се съсредоточим върху това, което имаме в CRA и самата React. По принцип, за да разделим кода на различни парчета, можем да използваме import() който работи благодарение на Webpack (import самият е предложение от етап 3 към момента, така че все още не е част от езиковия стандарт). Всеки път, когато Webpack види import, той ще знае, че трябва да започне разделянето на кода на този етап и не може да го включи в основния пакет (кода, който е вътре в импортирането).

Сега можем да го свържем с React.lazy() което изисква import() с файлов път, съдържащ компонента, който трябва да бъде изобразен на това място. След това можем да използваме React.suspense() което ще покаже различен компонент на това място, докато импортираният компонент не бъде зареден. Човек може да се чуди; ако внасяме един компонент, тогава защо ще ни е необходим?

Това не е съвсем така, тъй като React.lazy() ще показва компонента we import(), но import() може да извлече по-голяма част от този единичен компонент. Например, този конкретен компонент може да има други библиотеки в теглене, повече код и т.н., така че един файл не е необходим - може да има много повече файлове, обединени заедно. И накрая, можем да обгърнем всичко това в ErrorBoundary (можете да намерите кода в нашия раздел за границите на грешките) което ще служи като резервен вариант, ако нещо се провали с компонента, който искахме да импортираме (напр. ако има мрежова грешка).

оптимизиране на производителността в sql сървър

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

Това е основен пример, но очевидно можете да направите повече. Можете да използвате import и React.lazy за динамично разделяне на маршрута (например администратор срещу редовен потребител или просто наистина големи пътища, които носят много). Имайте предвид, че React.lazy от този момент поддържа само експортиране по подразбиране и не поддържа визуализиране от страна на сървъра.

Изпълнение на реагиращия код

Що се отнася до производителността, ако вашето приложение React действа изоставащо, има два инструмента, които могат да ви помогнат да разберете проблема.

Първият е Раздел за производителност на Chrome , което ще ви каже какво се случва с всеки компонент (например монтиране, актуализиране). Благодарение на това трябва да можете да идентифицирате кой компонент има проблеми с производителността и след това да го оптимизирате.

Другият вариант е да се използва DevTools Profiler която стана достъпна в React 16.5+ и със сътрудничеството на shouldComponentUpdate (или PureComponent, което беше обяснено в част първа от този урок ), можем да подобрим производителността на някои критични компоненти.

Очевидно е да се използват основни най-добри практики за мрежата, като например премахване на някои събития (например превъртане), предпазливост при анимациите (използване на преобразуване вместо промяна на височината и анимиране) и т.н. Използването на най-добрите практики може да бъде пренебрегнато много лесно, особено ако просто се справяте с React.

Състоянието на реакция през 2019 г. и след това

Ако трябваше да обсъждаме лично бъдещето на React, нямаше да съм много загрижен. От моя гледна точка React няма да има проблеми да запази трона си през 2019 г. и след това.

React има толкова силна позиция, подкрепена от голяма общност, че ще бъде трудно да се детронира. Общността на React е страхотна, не се изчерпват идеи и основният екип непрекъснато работи за подобряване на React, добавяне на нови функции и отстраняване на стари проблеми. React също е подкрепен от огромна компания, но проблемите с лицензирането са изчезнали - в момента е лицензиран за MIT.

Да, има няколко неща, които се очаква да бъдат променени или подобрени; например, да направите React малко по-малък (една от споменатите мерки е премахване на синтетични събития) или преименуване className до class. Разбира се, дори тези на пръв поглед незначителни промени могат да причинят проблеми като засягане на съвместимостта на браузъра. Лично аз също се чудя какво ще се случи, когато WebComponent придобие по-голяма популярност, тъй като може да увеличи някои от нещата, с които React често се използва днес. Не вярвам, че те ще бъдат пряк заместител, но вярвам, че може да се допълват добре.

Що се отнася до краткосрочните, куките току-що дойдоха в React. Това е може би най-голямата промяна, откакто се е случило пренаписването в React, тъй като те ще отворят много възможности и ще подобрят допълнителни функционални компоненти (и те наистина са хип-хоп сега).

И накрая, тъй като това е, което правя наскоро, има React Native . За мен това е страхотна технология, която се промени толкова много през последните няколко години (липсата на реакционна връзка е вероятно най-големият проблем за повечето хора и очевидно има много грешки). React Native пренаписва ядрото си и това трябва да се направи по подобен начин на пренаписването на React (всичко е вътрешно, нищо или почти нищо не трябва да се променя за разработчиците). Асинхронно изобразяване, по-бърз и лек мост между родния и JavaScript и други.

В екосистемата на React има какво да очакваме с нетърпение, но актуализациите (и React Native, ако някой обича мобилни телефони) са може би най-важните промени, които ще видим през 2019 г.

Свързани: Извличане на данни със застояло време при повторно потвърждаване с React Hooks: Ръководство

Разбиране на основите

Какво представляват куките React?

Куките са функции, които ви позволяват да се „закачите“ за състоянието на React и характеристиките на жизнения цикъл от функционалните компоненти.

Какво е нещо, което си струва да запомните за тях?

Те трябва да започват с 'use' и трябва да се извикват само от функциите на React компонент. Можете също така да създадете свои собствени куки!

Има ли смисъл неконтролираните компоненти?

В някои ситуации да. При качването на файлове те са необходими, но в повечето случаи с контролираните компоненти се работи по-лесно.

Може ли всичко това да се използва в React Native?

Най-вече. На първо място, производителността, свързана с разделянето, не е налице в RN (това може да се направи, но не и от кутията - трябва да бъде доста хакнато, тъй като Metro все още не работи с такива неща). Всичко останало се отнася за RN.

Кой ref трябва да използвам?

НЕ използвайте наследения. Предпочитаният метод е да се използва createRef, но обратното повикване трябва да е добре.

Куки, HOC или изобразяване на подпори?

Ако нещо може да се реши с куки, бих използвал куки. С тях е много по-лесно (поне за мен) да работя, тъй като изглежда, че е по-лесно да се споделят с различни компоненти и те не носят пирамида на обречеността в случай на рендер реквизит или „откъде идва това“ в HOCs.

Защо куките бяха толкова очаквани?

Те могат да решат някои проблеми със споделянето на код, които сме имали преди с използване на HOC, и да изобразяват реквизитни модели, които понякога могат да направят код малко сложен без причина.