React, визуализирано — react.gg е изцяло новият интерактивен начин за овладяване на съвременния React. Ограничената частна бета версия започва това лято. За актуализации на курсове, изключителни отстъпки, визуализации и някои забавни изненади, пуснете своя имейл по-долу.
ИСТОРИЯТА НА МРЕЖАТА
За да оцените наистина React, първо трябва да разберете историческия контекст защо е създаден React. От jQuery, до Backbone, до AngularJS — всяка ера вдъхновява React по различни начини.
Туитнете това Споделете това Копирайте URL
jQuery беше най-популярният начин за изграждане за уеб. Той прегърна уебсайтовете за това, което наистина бяха, дърво от DOM възли.
VIEWDOMPIZZAFYTACOFYRESET
С jQuery състоянието на вашето приложение живее в DOM. Всеки път, когато искахте да актуализирате това състояние, трябва задължително да преминете през DOM, да намерите възела, който искате да актуализирате, след което да го актуализирате. Трябва да отговорите на събитие? Отново обходете DOM, намерете възела, след което добавете слушател на събития към него.
Backbone.js изобрети шаблона Model-View-Controller. Това е шега, но това беше първата популярна рамка на JavaScript, която прегърна традиционния модел на софтуерен дизайн и го доведе до изграждане за уеб.
MODELSVIEWSPIZZAFYTACOFYRESET
Само с 2000 реда код Backbone ви позволи да отделите състоянието на приложението си от DOM. Вместо да живее в DOM, Backbone държавата живееше вътре в своите „модели“. Оттам нататък, когато даден модел се промени, всички изгледи, които се интересуват от състоянието на този модел, ще се рендират отново.
AngularJS, за добро и за лошо, прегърна двупосочно обвързване на данни. Това беше начинът на Angular да актуализира изгледа, когато моделът се промени, и да актуализира модела, когато изгледът се промени.
MODELSVIEWPIZZAFYTACOFYRESET
На теория това беше хубаво, защото не трябваше да се притеснявате сами да правите ръчна манипулация на DOM. На практика, неявните промени в състоянието обикновено водят до код, който е труден както за следване, така и за отстраняване на грешки. Това също води до проблеми с производителността, тъй като Angular.js трябваше постоянно да сканира приложението ви в търсене на промени в състоянието.
НАЧИНЪТ НА РЕАГИРАНЕ
Проблемът с повечето UI библиотеки и рамки преди React беше, че те не се справяха добре с мутациите. Това естествено доведе до приложения, които бяха трудни за отстраняване на грешки и трудни за следване. Но какво ще стане, ако можете напълно да избегнете този проблем? Сега очевидно не можете напълно да избегнете мутациите, но можете ли да създадете абстракция, която минимизира отрицателните им ефекти?
Това е в основата на това, което React се опитва да направи.
Туитнете това Споделете това Копирайте URL
Едно от основните нововъведения на React беше, че направиха View функция на състоянието на вашето приложение. Често се представя като v = f(s).
tateunctioniewv=fs)(
Всичко, което трябва да направите, е да се тревожите за това как се променя състоянието на вашето приложение, а React ще се справи с останалото.
Но да направите своя възглед за функция на вашето състояние всъщност беше само половината от картината. Истинската иновация се случи, когато капсулирате тази идея в подходящ API, базиран на компоненти.
) )= f ( g (VIEWsPIZZAFYTACOFYRESET
Правейки това, същата интуиция, която имате за създаването и композирането заедно на функции, може директно да се приложи към създаването и композирането на компоненти. Въпреки това, вместо да композирате функции заедно, за да получите някаква стойност, можете да съставите компоненти заедно, за да получите някакъв потребителски интерфейс.
За да приеме наистина API, базиран на компоненти, React се нуждаеше от начин, който да ви позволи да опишете как би изглеждал потребителският интерфейс за даден компонент от самия компонент. Това е мястото, откъдето идва по-голямата част от първоначалната омраза към React и това е свързано с интерпретацията на React на принципа „Разделяне на загрижеността“.
HTMLCSSJS
Исторически начинът, по който се придържахте към това в мрежата, беше вашият HTML да бъде отделен от вашия CSS, който беше отделен от вашия JavaScript.
По мнението на React, всичко, което има общо с изобразяването на изгледа - независимо дали това е състояние, потребителски интерфейс и в някои случаи дори стил, е част от неговата загриженост.
КОМПОНЕНТИHTMLCSSJS
Този подход ви позволява да локализирате проблеми, независимо от технологиите.
За да постигне това, React имаше нужда от начин, който да ви позволи да опишете как ще изглежда потребителският интерфейс за даден компонент от самия компонент. Е, описването на потребителския интерфейс вече е решен проблем - това е, в което HTML е наистина добър. Но не можете да смесвате HTML и JavaScript, нали?
Защо не? Това мислене доведе до създаването на JSX — прекрасно дете на HTML и JavaScript, което ви позволява да пишете синтаксис, изглеждащ като HTML, директно в JavaScript.
react.gg е изцяло новият интерактивен начин за овладяване на съвременния React.
Ограничената частна бета версия започва това лято. За актуализации на курсове, изключителни отстъпки, визуализации и някои забавни изненади, пуснете своя имейл по-долу.
Мека продажба
Трудна продажба
Имейл адрес
ИЗПРАТИ ГО
ПОДХОДЯЩ РЕКВИЗИТ
Всеки път, когато имате система, която разчита на състава, е изключително важно всяка част от тази система да има интерфейс за приемане на данни извън себе си. React постига това чрез подпори.
Туитнете това Споделете това Копирайте URL
Реквизитите са за компонентите, каквито са аргументите за функциите.
ПРОПУСВАНЕ НА РЕЗЕКТИВ
Същата интуиция, която имате за функциите и предаването на аргументи към функциите, може да се приложи директно към компонентите и предаването на реквизити към компонентите.
Заедно с предаването на данни към компонентите като атрибути, можете също да предавате данни между отварящите и затварящите скоби на даден елемент. Когато направите това, тези данни са достъпни в компонента чрез props.children.
Можете да мислите за компонент с children prop като за контейнер, който може да бъде запълнен от неговия родителски компонент.
{props.children}VIEWfunctionLayout (props) {return (‹div className=”layout”›‹/div›‹SideBar /›‹Footer /›{props.children}})‹Layout›‹/Layout›‹Pizza /› ‹Taco /›PIZZAFYTACOFY
Поради това е обичайно да се използва children за създаване на компоненти от тип Layout, които капсулират стил и логика, но оставят съдържанието на потребителя на компонента.
УПРАВЛЯВАЩА ДЪРЖАВА
Състоянието, и по-специално възможността отделните компоненти да притежават и управляват собственото си състояние, е това, което прави React толкова мощен, и това е, което ви позволява да изграждате сложни потребителски интерфейси от прости, изолирани компоненти.
Туитнете това Споделете това Копирайте URL
Тъй като компонентите на React са просто функции, нормалните променливи няма да се запазят при различни извиквания на тези функции (които React извиква рендери). За да добавите състояние, което продължава в различни рендери, можете да използвате куката useState на React.
Всеки път, когато React види, че състоянието на даден компонент се е променило, той ще задейства повторно изобразяване и ще актуализира потребителския интерфейс.
COMPONENTupdate()VIEW
АКТУАЛИЗИРАНЕ
Най-големият компромис с това отделните компоненти да управляват собственото си състояние е, че често ще имате състояние, до което множество компоненти трябва да имат достъп. Да се научите да се справяте с тези сценарии е един от най-важните аспекти на правилното управление на състоянието в React.
Ето основното правило — всеки път, когато имате състояние, от което зависят множество компоненти, ще искате да повдигнете това състояние до най-близкия родителски компонент и след това да го предадете надолу през реквизит.
СЪСТОЯНИЕ НА ЛИФТ
Единствената грешка е как актуализирате това състояние. Често пъти, когато състоянието на повдигане се активира, вие отделяте мястото, където съществува състоянието, от манипулаторите на събития, които актуализират това състояние.
За да разрешите това, ще създадете функция за актуализиране в родителския компонент, където се намира състоянието, и чрез реквизити ще извикате тази функция от дъщерния(ите) компонент(и), където се намира манипулатора(ите) на събитието.
()актуализация()актуализация()
LIFT STATEADD UPDATE FUNCTIONUPDATE
Ето как би изглеждало това в просто приложение Todo. Вместо всеки отделен Todo компонент да управлява собственото си състояние, бихме вдигнали това състояние до родителски компонент TodoList, след което ще предадем функция, която дава на всеки отделен Todo компонент възможността да се актуализира.
‹TodoList /›1‹Todo /›112‹Todo /›223‹Todo /›33
АКТУАЛИЗИРАНЕ АКТУАЛИЗАЦИЯ
СЪСТОЯНИЕ НА ЛИФТ
Но всички тези разговори за състояние повдигат добър въпрос, как точно React актуализира своето състояние?
РЕНДЕР
Изобразяването е просто фантастичен начин да се каже, че React извиква вашия функционален компонент с намерението в крайна сметка да актуализира изгледа. Нека да видим какво се случва по време на този процес.
Туитнете това Споделете това Копирайте URL
Когато React изобразява компонент, се случват две неща.
Първо, React създава моментна снимка на вашия компонент, която улавя всичко необходимо на React, за да актуализира изгледа в този конкретен момент. реквизити, състояние, манипулатори на събития и описание на потребителския интерфейс (въз основа на тези реквизити и състояние) са заснети в тази моментна снимка.
МОМЕНТНА СНИМКА НА ИЗГЛЕДИ НА КОМПОНЕНТИ
Оттам React взема това описание на потребителския интерфейс и го използва, за да актуализира изгледа.
След като вече знаете как React изобразява, естественият следващ въпрос е кога React изобразява? Отговорът е изненадващо прост. React ще рендира само когато състоянието на компонент се промени.
Ето как работи. Когато се извика манипулатор на събитие, този манипулатор на събитие има достъп до реквизитите и състоянието, каквито са били в момента на създаването на моментната снимка.
handleToggleCOMPONENTVIEWSNAPSHOTTGLE И RE-RENDER
Оттам, ако манипулаторът на събитие съдържа извикване на функцията за актуализиране на useState и React види, че новото състояние е различно от състоянието в моментната снимка, React ще задейства повторно изобразяване на компонента – създаване на нова моментна снимка и актуализиране на изгледа.
Можем да видим този процес в действие с това много просто приложение.
Всеки път, когато се щракне върху нашия бутон, нашият манипулатор на събития handleClick ще се стартира. Състоянието (index) вътре в handleClick ще бъде същото като състоянието в най-новата моментна снимка. Оттам React вижда, че има извикване към setIndex и че стойността, предадена към него, е различна от състоянието в моментната снимка - задействайки повторно изобразяване.
Това са много думи. Ето как би изглеждало, ако го визуализираме.
handleClickCOMPONENTVIEWSNAPSHOT012HELLOHOLABONJOUR, TYLERNСЛЕДВАЩ ПОЗДРАВ СЛЕДВАЩ ПОЗДРАВ И ПРЕДНАЗНАЧАВАНЕ
Един аспект на изобразяването, който може да не е толкова интуитивен, е, че когато състоянието се промени, React ще изобрази отново компонента, който притежава това състояние, и всички негови дъщерни компоненти – независимо дали тези дъщерни компоненти приемат някакви подпори или не.
промяна()актуализация()актуализация
АКТУАЛИЗИРАНЕ НА ПРОМЯНА
Разбирам, че това може да изглежда странно по подразбиране. Не трябва ли React да рендерира само дъщерни компоненти, ако техните реквизити се променят? Всичко друго изглежда като загуба.
Първо, React е много добър в изобразяването.
Второ, предположението, че React трябва да рендерира само дъщерни компоненти, ако техните реквизити се променят, работи в свят, в който React компонентите винаги са чисти функции и реквизитите са единственото нещо, което тези компоненти трябва да рендират. Проблемът, както знае всеки, който е създал приложение React в реалния свят, е, че не винаги е така.
И трето, ако имате скъп компонент и искате този компонент да се откаже от това поведение по подразбиране и да рендира само когато неговите реквизити се променят, можете да използвате React.memo компонента от по-висок ред на React.
Уморихте ли се от скучни, остарели курсове по React?
Прекарахме последната година, създавайки react.gg — интерактивният начин за овладяване на модерния React.
Пуснете имейла си по-долу или вие и цялото ви родословно дърво ще бъдете прокълнати 🫶.
Мека продажба
Трудна продажба
Имейл адрес
ИЗПРАТИ ГО
УПРАВЛЕНИЕ НА ЕФЕКТИТЕ
Когато React изобразява, той го прави с цел евентуално актуализиране на потребителския интерфейс. Целият този процес трябва да бъде възможно най-бърз. За да бъде бърз, React трябва да може да изобразява, без да се натъква на странични ефекти.
Ако случаят е такъв, къде тогава да поставим страничните ефекти? Нека да разгледаме.
Туитнете това Споделете това Копирайте URL
Все още работим върху визуалните елементи за този раздел, но ето набор от правила, които следваме за управление на страничните ефекти в React.
ПРАВИЛО #0
Когато даден компонент се изобразява, той трябва да го прави, без да се натъква на странични ефекти
ПРАВИЛО #1
Ако страничен ефект се задейства от събитие, поставете този страничен ефект в манипулатор на събитие
ПРАВИЛО #2
Ако страничен ефект синхронизира вашия компонент с някаква външна система, поставете този страничен ефект вътре в useEffect
ПРАВИЛО #3
Ако страничен ефект синхронизира вашия компонент с някаква външна система и този страничен ефект трябва да се изпълни *преди* браузърът да рисува екрана, поставете този страничен ефект вътре в useLayoutEffect
ПРАВИЛО #4
Ако страничен ефект е абониране за външен магазин, използвайте куката useSyncExternalStore
НЕВИЗУАЛНИ СТОЙНОСТИ
Състоянието ви позволява да запазите стойност в изобразяването и да задействате повторно изобразяване, когато се промени.
Но понякога се нуждаете от начин да кажете на React, че искате да запазите стойност в изобразяването, но тази стойност няма нищо общо с изгледа и следователно React няма нужда да рендира отново, когато се промени. За това е реферът.
Туитнете това Споделете това Копирайте URL
useRef създава стойност, която се запазва при изобразяване, но няма да задейства повторно изобразяване, когато се промени.
COMPONENTupdate()VIEWref.current
ПРОМЯНА АКТУАЛИЗИРАНЕ
Референциите са удобни за проследяване на невизуално състояние като идентификатори на таймери или проследяване на DOM възли.
ТЕЛЕПОРТ НА ДАННИ
Всеки път, когато имате приложение, което е колекция от компоненти, има линейна връзка между размера на вашето приложение и колко трудно е да се сподели състоянието в това приложение.
Туитнете това Споделете това Копирайте URL
Вземете например този сценарий. Това, на което са ви учили е, че когато имате състояние, от което зависи множество компоненти, ще искате да повдигнете това състояние до най-близкия родителски компонент и след това да го предадете надолу чрез подпори.
СЪСТОЯНИЕ НА ЛИФТ
Това работи... през повечето време. Но какво се случва, ако вместо приложението ви да изглежда така, то изглежда така?
Рядко е, но има моменти, когато преминаването на подпори през междинни компоненти може да стане прекалено излишно в най-добрия случай или напълно неуправляемо в най-лошия.
Тъй като това е толкова очевидно ограничение на архитектура, базирана на компоненти, React идва с вграден API за разрешаване, наречен Context. Можете да мислите за Context като за възможност да телепортирате данни навсякъде във вашето компонентно дърво, без да е необходимо да предавате реквизити.
Това е буквално всичко, което прави – това е Wormhole, мостът Einstein-Rosen, TARDIS, Stargate, Portkey, DeLorean на React.
ИМА ОЩЕ
Все още има още няколко раздела, които трябва да изчистим, но се надяваме, че въпреки това ви е харесало.
Ако сте го направили и искате да проверите повече, разгледайте react.gg. Това е нашият поглед към забавен, интерактивен начин за овладяване на съвременния React.
Ограничената частна бета версия се отваря това лято.
