[Перевод] Понимание хуков React

внешний интерфейс JavaScript Программа перевода самородков React.js

На этой неделе,Sophie Alpertи я представил предложение «Крючки» на React Conf, после чегоRyan FlorenceПодробное введение в хуки:

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

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

Зачем нужны хуки?

Мы знаем, что компоненты и нисходящий поток данных могут помочь нам организовать большие пользовательские интерфейсы в небольшие, независимые, многократно используемые фрагменты.Однако мы часто не можем разбивать сложные компоненты дальше, потому что логика зависит от состояния и не может быть абстрагирована на функции или другие компоненты.. Это то, что люди иногда имеют в виду, когда говорят, что React не позволяет им «разделять задачи».

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

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

Мы считаем, что хуки — лучший способ решить все эти проблемы.Хуки позволяют организовать логику внутри компонентов в повторно используемые изолированные блоки.:

Хуки применяют философию React (явный поток данных и композиция) внутри компонентов, а не только между компонентами.. Вот почему я считаю, что хуки идеально подходят для компонентной модели React.

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

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

Будут ли хуки раздувать React?

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

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

Что касается размера развертывания, поддержка хуков добавляет к размеру React всего около 1,5 КБ (min + gzip). Немного, но поскольку код, использующий хуки, часто можно сжать меньше, чем эквивалентный код, использующий классы,Таким образом, использование хуков также может уменьшить размер пакета.. Следующий пример немного экстремальный, но он эффективно демонстрирует, почему я это говорю (нажмите, чтобы увидеть весь пост):

Предложение Hooks не содержит каких-либо критических изменений.. Даже если вы внедрите хуки в свои недавно написанные компоненты, ваш существующий код все равно будет работать как обычно. На самом деле, это именно то, что мы рекомендуем — никаких серьезных изменений! Использование хуков в любом критичном коде — хорошая идея. А пока, если вы сможете попробовать альфа-версию 16.7 иHooks proposalа такжеreport any bugsОбратная связь с нами будет принята с благодарностью.

Что такое хуки?

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

Сегодня существует множество способов повторного использования логики в приложениях React. Мы можем написать простую функцию и вызвать их для выполнения некоторых вычислений. Мы также можем писать компоненты (которые сами могут быть функциями или классами). Компоненты более мощные, но они должны отображать некоторый пользовательский интерфейс. Это делает неудобным для них совместное использование невизуальной логики. Это вынудило нас прибегнуть к сложным паттернам, таким как реквизиты для рендеринга и компоненты более высокого порядка.Был бы React проще, если бы существовал только один простой способ повторного использования кода, а не так много??

Функции кажутся идеальным механизмом повторного использования кода. Организация логики между функциями требует минимальных усилий. Однако локальное состояние React не может содержаться внутри функции. Вы также не можете абстрагировать поведение «отслеживать размер окна и состояние обновления» или «анимировать значение с течением времени» из компонента класса без рефакторинга кода или абстрагирования Observables. Оба подхода разрушают простоту React, которую мы так любим.

Крючки решают именно эту проблему. Хуки позволяют вам использовать функции React (например, состояние) в функции, вызывая одну функцию. React предоставляет несколько встроенных хуков, раскрывающих «строительные блоки» React: состояние, жизненный цикл и контекст.

Поскольку хуки — это обычные функции JavaScript, вы можете комбинировать встроенные хуки, предоставляемые React, в свои собственные «пользовательские хуки».. Это позволяет вам превратить сложные проблемы в одну строку кода и поделиться ими со своим приложением или сообществом React:

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

Получите код!

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

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

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

Давайте посмотрим, как реализовать этот пользовательский хук. насИспользуйте локальное состояние React для сохранения текущей ширины окна и при изменении размера окна.Используйте побочный эффект для установки состояния:

как вы можете видеть сверху, какuseStateа такжеuseEffectТакие встроенные хуки React являются основными строительными блоками. Мы можем использовать их непосредственно в компоненте или интегрировать их в пользовательские хуки, такие какuseWindowWidthСюда. Использование пользовательских хуков так же удобно, как использование встроенного API React.

ты можешь начатьЭтот обзорУзнайте больше о встроенных хуках в .

Хуки полностью инкапсулированы  ——  Каждый раз, когда вы вызываете функцию хуков, она получает независимое локальное состояние от текущего исполняемого компонента.. Неважно для этого конкретного примера (все компоненты имеют одинаковую ширину окна!), но именно это делает хуки такими мощными. они не только общиеусловиеспособ обменалогика с сохранением состоянияПуть. Мы не хотим нарушать поток данных сверху вниз!

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

Вот пример библиотеки анимации React для экспериментальных хуков:

Запустите этот пример в CodeSandbox

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

(Если вы хотите узнать больше об этом примере, см.Это введение. )

Возможность передачи данных между хуками делает их хорошо подходящими для анимации, подписки на данные, управления формами и других состояний абстракции.В отличие от реквизитов рендеринга и компонентов более высокого порядка, хуки не создают «иерархии ошибок» в дереве рендеринга.. Они больше похожи на плоский список «ячеек памяти», связанных с компонентами. Никаких дополнительных слоев.

Куда должен пойти класс?

На наш взгляд, пользовательские хуки — самая привлекательная часть предложения хуков. Но для того, чтобы пользовательские хуки работали, React должен предоставить функциям способ объявлять состояние и побочные эффекты. И это точно такuseStateа такжеuseEffectТакие встроенные хуки позволяют нам что-то делать. ты сможешьДокументацияузнать о них.

Оказывается, эти встроенные хукине толькоМожет использоваться для создания пользовательских хуков. OнитакжеДостаточно определить компоненты, потому что они предоставляют нам все необходимые функции, такие как состояние. Это основная причина, по которой мы хотим, чтобы хуки определяли компоненты React в будущем.

Мы не планируем отказываться от классов. У нас в Facebook тысячи компонентов классов, и, как и вы, мы не собираемся их переписывать. Но если сообщество React поддерживает хуки, нет смысла рекомендовать два разных способа написания компонентов одновременно. Хуки могут охватывать все сценарии приложений классов, обеспечивая большую гибкость в абстрагировании, тестировании и повторном использовании кода. Вот почему хуки представляют наше видение будущего React.

Но являются ли крючки чем-то «волшебным»?

ты можешьПравила для хуковудивлен.

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

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

Мы уже месяц используем хуки в продакшене, чтобы посмотреть, не запутаются ли инженеры в правилах. Мы обнаружили, что люди привыкают к ним в течение нескольких часов. Лично я признаю, что поначалу эти правила «казались мне неправильными», но я быстро с этим справился. Этот опыт был похож на мое первое впечатление от React. (Вам вообще нравился React? По крайней мере, мне не нравился, и я не передумал до тех пор, пока не сделал еще несколько попыток.)

Помните, что в реализации хуков тоже нет «волшебства». как Джеймиуказать, это выглядит так:

Мы храним список хуков для каждого компонента и переходим к следующему элементу в списке каждый раз, когда вызываются хуки. Благодаря правилам хуков их порядок одинаков при каждом рендеринге, поэтому мы можем предоставить правильное состояние компонента для каждого вызова. Знайте, что React не нужно делать ничего особенного, чтобы узнать, какой компонент рендерится — вызовитеточноРеагировать.

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

Хуки не полагаются на прокси или геттеры, обычно встречающиеся в современных библиотеках JavaScript. Понятно, что хуки лучше некоторых популярных методов решения подобных задач.Четноекак правило. Я бы сказал, что хуки так же распространены, как вызовы array.push и array.pop (то же самое зависит от порядка вызовов!).

Хуки разработаны так, чтобы не иметь ничего общего с React. Фактически, в первые несколько дней после публикации предложения разные люди предлагали экспериментальные реализации одного и того же Hooks API для Vue, веб-компонентов и даже нативных функций JavaScript.

Наконец, если вы чисто функциональный программист и вас не устраивают детали реализации зависимости React от изменяемого состояния, вы будете рады узнать, что хуки завершения могут быть реализованы функциональным способом (если их поддерживает JavaScript). Конечно, React всегда полагался на внутреннее изменяемое состояние — вот почемутыНе нужно это делать.

Независимо от того, рассматриваете ли вы это с более прагматичной или догматической точки зрения (или вы делаете и то, и другое), я надеюсь, что по крайней мере одна позиция имеет смысл. Самое главное, я думаю, что хуки позволяют нам создавать компоненты с меньшими усилиями и обеспечивают лучший пользовательский опыт. Это именно то, что лично меня взволновало в Hooks.

Распространяйте позитивную энергию, а не шумиху

Если Крюки вам еще не нравятся, я вас полностью понимаю. Я все еще надеюсь, что вы сможете попробовать это на небольшом проекте и посмотреть, изменится ли ваше мнение. Если у вас есть проблема, для решения которой нужны хуки, или у вас есть другое решение, сообщите нам об этом через RFC!

Если яПозволятьВы взволнованы или просто немного любопытны, это здорово! У меня есть только один вопрос. В наши дни многие люди изучают React, и они сбиваются с толку, если мы торопимся писать учебники и заявляем, что функции, которые существуют всего несколько дней, являются лучшей практикой. Даже для тех из нас, кто работает в команде React, некоторые вещи о хуках не очень понятны.

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

Будьте вежливы, когда общаетесь с другими людьми, которые не так взволнованы, как вы. Если вы видите, что кто-то неправильно это понимает, вы можете поделиться с ним дополнительной информацией, если он захочет. Но любые изменения пугают, и как сообщество мы должны делать все возможное, чтобы помогать людям, а не отталкивать их. Если я (или кто-то еще в команде React) не последую этому совету, позвоните нам!

Сделайте еще один шаг вперед

Ознакомьтесь с документацией предложения Hooks для получения дополнительной информации:

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

Если что-то неясно, пожалуйста, дайте мне знать, и я буду рад ответить на ваши вопросы. Спасибо за прочтение!

Vitra — Portemanteau

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

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории