React стал довольно большим за последние несколько лет с 2013 года, и я хотел поделиться простым и замечательным пониманием React, которое заключается в разнице между состоянием и реквизитами, а также о том, как он обновлялся за последние годы.

В React, а также в других современных средах JavaScript, таких как Angular и Vue, основным подходом является использование компонентов.
Они позволяют создать очень простой и небольшой модуль, который содержит некоторую логику, отвечающую за эту область и только эта область.
В конце концов, компоненты являются строительными блоками для создания завораживающего веб-сайта.

Но что они на самом деле делают?
Короткий и простой ответ: все!
Компонентом может быть список контактов, с которым пользователь может взаимодействовать. Компонент будет отвечать за обработку каждой логической операции, связанной с ним, и, конечно же, отображать ее на экране.
Если мы посмотрим на другой пример на этой странице, на которой мы сейчас находимся, мы можем связать панель вверху с компонент, который называется ApplicationBar, это имя, которое я только что придумал, его можно назвать как угодно ☺

Причина использования компонентов и их максимально возможного разделения заключается в возможности повторного использования. Как и в библии всех программистов «Шаблоны проектирования», которые помогают нам проектировать наш код, с помощью компонентов приложение должно состоять из небольших компонентов, но что-то действительно важное — не делать их слишком маленькими.

Таким образом, когда мы сталкиваемся с ошибками и хотим расширить наше приложение на другой уровень или добавить некоторые функции, ничего не разрушая, мы можем сделать это довольно просто.

Это может показаться очень простым, и я открою вам маленький секрет.
На самом деле это очень просто, но иногда и сложно, если неправильно понять.

Чтобы сделать все возможное при создании компонентов.
Важным шагом является понимание используемой среды Javascript, и поэтому сегодня мы собираемся понять хлеб с маслом приложения React, которое является Состояние и свойства компонентов.

Компонент, нам нужно поговорить..

В ответ важно понять, что само приложение является компонентом, который использует другие дочерние компоненты, что помогает создавать само приложение, например, писать старомодное дерево тегов HTML.

Это позволяет нам создать древовидную иерархию, в которой родительские компоненты разговаривают со своими дочерними элементами и передают им данные для взаимодействия.

Более того, из-за этой иерархии мы можем собрать любой логический компонент и компонент пользовательского интерфейса в один небольшой фрагмент и повторно использовать его, где захотим.

Что-то, чем я занимался сам, — это искусство создания динамических компонентов. Под этим я подразумеваю создание компонента, который будет динамическим для изменений с точки зрения пользовательского интерфейса, то есть цветов, положения, анимации (CSS/SASS) для свойств, которые мы ему передаем.

Это искусство само по себе, потому что мы можем ввести себя в заблуждение, делая компонент «динамичным», но на самом деле мы делаем его слишком конкретным, так что, как и в шаблонах проектирования, с этим нужно быть осторожным :)

Например, однажды я попытался создать пользовательскую кнопку, в которой использовался созданный мной стиль SASS. Проблема заключалась в том, что я хотел использовать эту кнопку в большем количестве мест, и я добавил логику внутри компонента, что сделало его намного более сложным и слишком специфичным для задачи.
Я понял свою ошибку, когда захотел использовать эту кнопку. в другом месте, которые было немного сложно реализовать.

Вкратце, потому что у нас будет больше об этом, когда мы пойдем дальше, но в React у нас есть компонент класса и функциональный компонент.
Между ними есть небольшая разница, и мы ее тоже рассмотрим.

Какой к черту реквизит?

Реквизиты — это в основном неизменяемые данные, которые есть у компонента.
Реквизиты передаются компоненту от его родителя.

Неизменяемое означает то, что неизменно, а изменяемое — то, что можно изменить.

Какие варианты использования можно использовать для свойств, которые вы спрашиваете?
Допустим, мы хотим передать функцию обратного вызова дочернему компоненту, поэтому, когда дочерний компонент активирует ее, мы получим предупреждение об этом в родительском компоненте и сделаем некоторые функции, связанные с этим событием.
Фактическая функция не должна изменяться во время выполнения, потому что есть только одна функция, которая обрабатывает этот обратный вызов.

Другие способы могут заключаться в предоставлении некоторых переменных, которые постоянны в своем поведении, чтобы компонент мог отображать или использовать их любым способом, который он пожелает.

Реквизит исходил из идеи, что такой компонент, как человек, должен иметь какие-то свойства, определяющие его и его поведение.
Например, у человека есть сердце, легкие, ноги и все остальное. вещи внутри, которые нельзя заменить, потому что они являются основными свойствами, в которых человек должен жить, и в тех же отношениях, что и использование реквизита для компонента.

Я думаю, что предложение «картинка стоит тысячи слов» удивительно, и поэтому мы сейчас увидим пример функциональных компонентов:

Как мы видим, достаточно просто передать переменные в компонент, который можно использовать в этом примере, чтобы просто отобразить их.

Это здорово и все такое, но как насчет случаев, когда мне нужно что-то, что можно изменить, или переменные, которые обновляются в моем родительском компоненте, а также должны быть обновлены в моих дочерних компонентах?

Что ж, отличный вопрос, и я рад, что вы его задали, для этого у нас есть кое-что удивительное, которое называется состоянием, и мы собираемся скрыть это прямо сейчас :)

У кого есть мое состояние?

Ранее мы говорили о человеке и его органах. Теперь мы собираемся использовать более стильную или красивую аналогию для этого, лол :)

Все люди постоянно носят довольно разную одежду, и каждый предмет одежды заставляет нас воспринимать их по-разному.
Конечно, каждый может переодеться, когда покупает новую одежду, или просто хочет переодеться, когда ему нужно. к.

На самом деле это аналогия состояния.
Состояние похоже на свойства для каждого компонента, которые могут быть изменены во время выполнения, и они создают его сами.

Мы можем создавать значения параметров состояния, создавая новые значения, или даже использовать значения свойств, переданных нам от родителя.
Само состояние представляет собой объект JSON, который может иметь внутренние объекты, массивы и отдельные переменные. по мере необходимости, и это может выглядеть так:

Когда мы хотим изменить состояние, мы можем выполнить следующий код внутри компонента:

Крутая вещь в setState заключается в том, что мы можем получить обратный вызов, который завершит обновление состояния для любых дополнительных функций, которые мы хотим добавить.

Когда вы хотите использовать состояние для компонента, вам нужно использовать компонент класса или другую новую технику, называемую хуками, которую мы увидим позже.
А пока давайте посмотрим на компонент класса для человека:

Компонент класса позволяет получить доступ к жизненному циклу компонента, такому как componentDidMount и многим другим,все они являются обратными вызовами, которые сообщают, как и его имя, что компонент только что прошел какое-то событие. .

Сегодня, когда мы разрабатываем любое приложение React, мы стремимся использовать функциональные компоненты, потому что их легко отлаживать и поддерживать.
Кто-то может сказать, что они обеспечивают лучшую производительность из-за того, что не используются обратные вызовы жизненного цикла и этап.
К сожалению, тестов, подтверждающих это, нет.

Но если для функционального компонента нет состояния, как мы можем обрабатывать изменяемые данные в функциональном компоненте?
Из-за этого команда React создала хуки, которые позволяют использовать несколько хуков, которые компенсируют недостающие функции функциональных компонентов.

Капитан крюк путь!

Сегодня в React есть предложение использовать хуки вместо компонентов класса.
Причина этого снова в том, что функциональные компоненты легко отлаживать и поддерживать.

Основные крючки:

  • useState(someKindOfValue) — создает состояние определенной переменной внутри нашего компонента.
  • useEffect(() =› {}, [stateValue]) — позволяет получать события, касающиеся отрисовки компонента и его жизненного цикла. Мы можем передать ему состояния, которые мы создаем. Таким образом, когда мы обновляем состояние, вызывается обратный вызов, который мы передали ему, поэтому мы получаем обновление о состоянии, которое оно изменило.
    Кроме того, при создании компонента также вызывается обратный вызов.

Мы сосредоточимся на useState, потому что мы можем много говорить о каждом из них.
При вызове useState мы присваиваем ему значение по умолчанию для параметра состояния.
Мы можем дать ему все, что пожелаем, например дать свойство компонента, переданное от родительского компонента, как мы говорили в разделе «Компоненты класса».

Вы можете видеть ниже, что мы на самом деле возвращаем 2 параметра, и вам может быть интересно, что это такое.
В основном для каждого параметра состояния, который мы создаем, мы деструктурируем параметр и обработчик, который помогает нам обновить состояние для этого свойства. .

На самом деле я только что закончил разработку своего блога с помощью React и обнаружил хуки, и должен сказать, что они мне очень нравятся.
Они значительно упростили мой код, а также упростили отладку и поддержку.

Но мы все говорили о состоянии и свойствах, и мы не очень понимаем, как они на самом деле работают.
Итак, теперь мы собираемся начать теоретическую часть, так что берите чашку кофе или мишку и готовьтесь :)

Как все это влияет на интерфейс?

HTML-страница описывается DOM, как вы, возможно, уже знаете.
Внутри React у нас есть виртуальный DOM, который помогает рендерить только те вещи, которые нужно отрендерить снова, а не сам DOM целиком.

Но как он это делает спросите вы? Отличный вопрос!

Когда компонент меняет свое состояние, он запускает для дочерних компонентов (которые получили поля из состояния в качестве опоры) событие, чтобы сообщить им, что им нужно снова отобразить себя.

На самом деле это еще больше говорит нам о том, насколько маленькими должны быть наши компоненты, потому что, если они будут такими, производительность с точки зрения живого рендеринга самого приложения может взлететь до небес, если все это сделать правильно.
Это непростая работа. делай так, а с возрастом приходит мудрость ☺

Совет

При использовании реквизита существует такой тип поведения, который заставляет людей, которые начинают работу, реагировать так же, как я, и даже самые упорные разработчики реакции делают то, что называется бурением реквизита.
Это не что-то преднамеренное, но это может произойти, когда мы спешим к делу.

Чтобы понять, что это значит, очень подробно, давайте воспользуемся следующей аналогией.

Допустим, младший ребенок в семье хочет попросить у отца дополнительное пособие, потому что он потратил все свои деньги в игровом магазине и ему нужно больше.

Родитель дает пособие старшему сыну, а по возрастной иерархии оно достается младшему сыну.

Что будет, если кто-то из детей решит пошалить или заберет немного денег себе и скажет, что вместо 25$ было 20$, это отличный доход, если делать это каждый день, лол.

В этом прекрасном коротком рассказе мы поняли, я надеюсь, что предоставление свойств компоненту через цепочку компонентов может быть проблематичным, если что-то по пути не обрабатывается должным образом.

Вот почему при использовании реквизита мы должны быть очень осторожны, чтобы не добавить лишний функционал или изменить его из-за невообразимых ужасов.

Как мы можем преодолеть такое, спросите вы?
Продолжить чтение :)

Компонент и не только!

Я не хочу заставлять вас ждать слишком долго, но я хочу сказать, что при работе с состоянием и компонентами мы должны быть как можно меньше, чтобы делать то, что нужно компоненту в его зоне ответственности.

Я могу рассказать вам о чем-то, что помогает вам в написании общего состояния приложения, что-то вроде статических или глобальных переменных, которые используются всеми компонентами, о чем вы, возможно, догадались, помогает предотвратить сверление реквизита.

Огромными игроками в этой области являются Mobx и Redux.
Они помогают создать глобальное состояние, подобное нашему приложению, к которому мы можем получить доступ из любого компонента.

Честный отказ от ответственности — я использовал Redux и Mobx в компонентах класса, но я не использовал их с функциональными компонентами и хуками.
Так что я надеюсь, что в будущем мы вместе увидим новый материал на эту тему.

Они оба — замечательная тема для разговора, но если мы сделаем это сейчас, этот пост будет слишком длинным, и они заслуживают отдельного поста :)

В заключении

Мы сделали (надеюсь) отличный подробный обзор свойств и состояния компонентов React, а также типов компонентов, которые у нас есть сегодня.
Мы также увидели новенького в этом блоке — хуки React.< br /> Более того, мы немного поговорили о том, как проектировать React-приложение.

Как всегда, я надеюсь, что вам понравилось читать эту статью, и если у вас есть какие-либо предложения по улучшению этой статьи, чтобы всем остальным она понравилась и получила лучший опыт, я буду очень рад услышать :)

Еще раз спасибо и желаю вам отличного пути!