Прочитав эту статью, вы узнаете

  • Предварительное понимание статус-кво хуков в vue и react
  • Понимание «Зачем нам нужны хуки»
  • Попрактикуйтесь с простыми хуками

1. крючки: общая тенденция

В начале 2019 года в React официально появились хуки в версии 16.8.x.

В июне 2019 года Эван Ю предложил API-интерфейс компонента vue3 в разделе vue/github-issues. (Основа Vue Hooks)

В последующих версиях react и vue3 хуки принимают все больше и больше людей. Кроме того, такие фреймворки, как solid.js и preact, также начали присоединяться к семейству хуков.

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

2. Что такое крючки?

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

Когда система работает до определенного периода, она вызывает функцию обратного вызова, зарегистрированную на это время.

Наиболее распространенными хуками являются: хуки системы Windows могут отслеживать различные события системы, а onload или addEventListener, предоставляемые браузером, могут регистрировать методы, которые вызываются в разное время в браузере.

Но очевидно, что слову хуки придается особое значение в рамках конкретной темы в определенной области. До [email protected], когда мы говорили о хуках, мы, вероятно, говорили о «жизненном цикле компонента».

Но теперь хуки имеют совершенно новое значение. Возьмем в качестве примера реакцию:

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

Простыми словами:

Набор методов, обеспечивающих возможность разработки функциональных компонентов. (Запомните это ключевое слово: функциональные компоненты)

В vue определение хуков может быть более неясным, поэтому давайте подытожим:

В API-интерфейсе композиции vue ряд методов, начиная с «use», предоставляет возможности разработки, такие как повторное использование компонентов и управление состоянием. (Ключевые слова: API-интерфейс композиции)

В соответствии с этим стандартом определение хуков в vue и react похоже. Реакции и хуки vue немного отличаются:

  • React: «хуки» можно использовать только внутри «функциональных компонентов».
  • Vue: «хуки» можно использовать только в жизненном цикле «установки».

3. Правила крючков

Обычно имена хуков начинаются с использования, и эта спецификация также включает наши пользовательские хуки.

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

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

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

4. Зачем нужны крючки?

4.1 Лучшее повторное использование состояний

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

Предположим, у вас есть следующие требования:

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

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

Код выглядит следующим образом: (Этот пример написан на миксине vue2)

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

Недостаток 1: трудно отследить методы и свойства!

Только представьте, если появится такой код, будете ли вы сомневаться в своей жизни:

or:

Недостаток 2: покрытие, одно и то же имя? Так запутанно!

Когда я хотел смешать и mixin-a.js, и mixin-b.js, чтобы получить их возможности одновременно, случилось кое-что неприятное:

И mixin-a.js, и mixin-b.js определяют this.name как свойство. В настоящее время вы глубоко сомневаетесь, является ли миксин научным способом повторного использования.

Недостаток 3. Хотите микшировать несколько раз? За это придется заплатить большую цену!

Продолжая говорить о приведенном выше примере, если мои потребности изменятся, мне больше не нужно простое имя состояния, а имя и фамилия соответственно. На этом этапе возможность микширования name-mixin.js будет очень неудобной, потому что я не могу микшировать один и тот же файл дважды.

Конечно, есть решения, такие как:

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

Поэтому крайне актуальным стало новое «повторное использование логики состояния» — это хуки!

Метод записи мультиплексирования состояния перехватчика:

По сравнению с миксинами они просто потрясающие!

  1. Можно ли отследить методы и свойства? Это слишком просто, и с первого взгляда понятно, кто это произвел и откуда взялся.
  2. Будут ли повторяющиеся имена и проблемы с покрытием? Точно нет! Внутренние переменные находятся внутри замыкания, а возвращаемые переменные поддерживают определение псевдонимов.
  3. использовать много раз? Совершенно никаких проблем! Разве приведенный выше блок кода не используется три раза?

Просто по причине «повторного использования логики состояния» хуки уже вызвали у меня желание попробовать

4.2 Организация кода

Уменьшение энтропии: от космологии до философии кодирования.

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

Но на странице код из N вещей запутанных друг с другом в компоненте — это действительно очень распространенное явление до появления хуков.

Итак, какие улучшения может внести написание хуков в организации кода?

Будь то vue или react, это можно сделать с помощью написания хуков, а «блоки кода, разбросанные по разным циклам объявлений» можно агрегировать вместе с помощью хуков.

Преимущества этого очевидны: «высокая агрегация, улучшенная читабельность». Что приходит с этим, так это «повышенная эффективность и меньше ошибок».

Согласно теории в «физике», такая организация кода есть «уменьшение энтропии».

4.3 Легче понять, чем компоненты класса

В компонентах класса реакции вы повсюду можете увидеть всевозможные .bind(this). (Даже в официальной документации есть специальный раздел, описывающий вопрос «Зачем нужна привязка?»)

Игроки Vue не смейтесь, это в вычисляемом: { a: () =› { this } } также не определено.

Очевидно, что хотя привязка и является «необходимой», это не «преимущество», а область «высокой частоты отказов».

Но со способом написания Hooks вам вообще не нужно беспокоиться об «этом». Больше не нужно беспокоиться о том, что вы забыли написать bind.

4.4 Дружелюбно, постепенно

И vue, и react просто предоставляют Hooks API и помещают туда свои плюсы и минусы. Нет неприемлемых изменений, которые вынуждают вас использовать хуки для перезаписи компонентов предыдущего класса.

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

Но тенденция ясна, все больше и больше людей присоединяются к армии хуков и компонуемых API.

5. Как начать использовать хуки?

5.1 Среда и версия

В проекте реакции версия реакции должна быть выше 16.8.0.

В проекте vue vue3.x — лучший выбор, но vue2.6+ с @vue/composition-api также позволяет начать получать удовольствие от composition API.

5.2 Как писать хуки в React

Поскольку react Hooks поддерживает только «функциональные» компоненты, вам необходимо создать функциональный компонент, такой как my-component.js.

Для получения более подробной информации, пожалуйста, обратитесь к реакции официальный сайт.

5.3 Как писать хуки в vue

Метод написания хуков Vue основан на API композиции, поэтому в этом примере используется «настройка скрипта» для записи:

Очевидно, что API, который выполняет работу, связанную с useState и useMemo в составном API vue, не имеет имени useXxx, а следует за ref и вычисляется, которые унаследованы от Vue.

Хотя это не соответствует соглашению Hook, определенному react Hook, кажется, что нет ничего плохого в том, что API vue не следует соглашению react.

Для получения более подробной информации, пожалуйста, обратитесь к официальному сайту Vue.

6. Запустите первый пользовательский хук

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

В сообществе с открытым исходным кодом также есть много хороших пакетов на основе хуков, таких как ahooks (ahooks.js) и vueuse (vueuse.org).

Итак, с чего нам начать писать «пользовательские хуки»? Смотри вниз!

6.1 реакция игроков смотрите здесь

На официальном веб-сайте React есть специальная глава Пользовательский хук.(https://reactjs.org/docs/hooks-custom.html

Здесь мы по-прежнему используем требование useName в начале статьи в качестве примера, надеясь добиться эффекта:

Если мы хотим добиться вышеуказанного эффекта, как нам написать код?

Не могу не вздохнуть снова, по сравнению с миксинами, его не только лучше использовать, но и проще определить.

6.2 Игроки Vue смотрите здесь

На официальном сайте vue3 нет введения в геймплей пользовательских хуков, но реализовать его несложно.

Цель также состоит в том, чтобы реализовать метод useName:

6.3 Сходства и различия между кастомными хуками vue и react

  • Сходства: общая идея одна и та же, и все они следуют основным идеям «определения данных о состоянии», «данных о рабочем состоянии» и «скрытия деталей».
  • Различия: существуют существенные различия между составным API и функциональными компонентами React
    В компонентах vue3 настройка существует как жизненный цикл, предшествующий «созданию». В любом случае он будет введен только один раз в процессе рендеринга компонента.
    Компоненты функции React совершенно разные. Если они не «запомнены», они могут постоянно запускаться, постоянно вводить и выполнять методы, так что умственных накладных расходов на самом деле больше, чем vue.

Спасибо за прочтение, увидимся в следующий раз