Hook config center windows что это
Особенности внедрения DLL и установки хуков в Modern-приложениях Windows 8/10
Для чего вообще нужно внедрять свои DLL-ки в чужие процессы и устанавливать там хуки? Для того, чтобы понять какие функции будет вызывать это приложение, с какими параметрами и что эти функции вернут. Таким образом мы можем понять внутреннюю логику работы этого приложения, узнать к каким файлам оно пытается получить доступ, какие данные пересылает по сети, мы можем добавить в него логирование, профилирование, отладить баг, получить из приложения некоторые данные или наоборот — добавить в его интерфейс что-нибудь нужное нам. Хуки использует известная утилита Spy++ для работы с окнами приложений, DirectX-отладчики вроде RenderDoc, некоторые утилиты от SysInternals, программы типа ApiMonitor и т.д.
Некоторое время назад я писал вводные статьи об использовании хуков на примерах библиотек Microsoft Detours и madCodeHook (если вы совсем не знакомы с хуками — это то, с чего можно начать). Описанных там техник достаточно для работы с обычными приложениями, но время не стоит на месте и вот сегодня у нас уже есть Metro Modern-приложения, входящие в комплект Windows 8 и Windows 10, а также распространяющиеся через Microsoft Store программы сторонних производителей. К примеру, новый браузер Spartan — это Modern-приложение. Внедрение DLL в эти процессы имеет свои особенности и на первый взгляд может даже показаться невозможным, но это не так. В этой статье я расскажу, как мы можем залезть внутрь Modern-приложения и установить в нём хуки в своих коварных целях.
32-битные и 64-битные приложения
Операционная система Windows бывает 32-разрядная и 64-разрядная. Соответственно, Modern-приложения тоже могут быть 32-битные либо 64-битные. При загрузке приложения в магазин Microsoft разработчик собирает обе версии (плюс еще, возможно, ARM), а Windows уже сам решает, какую загрузить пользователю. Отсюда следует очевидный вывод, что DLL-ка, которую мы будем внедрять в Modern-приложение, тоже должна быть в двух вариантах. Менее очевидный вывод в том, что приложение, которое будет «забрасывать» нашу DLL-ку в чужой процесс, тоже должно быть соответствующей битности. Нам ведь нужно запустить внутри чужого процесса поток, который загрузит нашу библиотеку и вызовет из неё какую-то функцию. Делается это через вызов CreateRemoteThread(Ex), а вот уже она требует одинаковой битности вызывающего и вызываемого процессов (а иначе как передавать адреса?).
Доступ к внедряемой DLL
Как вы, возможно, знаете, Modern-приложения живут в своих песочницах, откуда они имеют доступ только к своей папке и некоторым другим доступным для них (ограниченным) ресурсам ОС. К примеру, Modern-приложение не может вот просто так взять и открыть любой файл с диска. Для нас это означает то, что попытавшись заставить чужое приложение подгрузить нашу библиотеку в своё адресное пространство — мы получим ошибку доступа. Это можно легко увидеть, воспользовавшись, к примеру, утилитой ProcMon.
Что же делать? Разрешить доступ к файлу внедряемой библиотеки для Modern-приложений. Для этого есть системная утилита icacls. Вот эта команда открывает доступ к файлу на диске для всех Modern-приложений:
Теперь ошибки доступа у нас не будет.
Линковка DLL-ки
Но не всё так просто. DLL-ка может иметь зависимости. И даже если вам кажется, что их нет — возможно, вы забываете о зависимости от VC++ Runtime Library. По умолчанию созданная в Visual Studio С++ библиотека предполагает динамическую линковку с рантайм-библиотекой С++. Это означает, что когда какое-то приложение захочет загрузить вашу библиотеку — функция LoadLibrary() первым делом увидит, что вам необходима, к примеру, библиотека msvcp90r.dll и попытается её найти, что вобщем-то, получится если речь идёт об обычном (не Modern) приложении и наличии соответствующего VC++ Redistribution Package. Что касается Modern-приложений, то порядок поиска DLL-ок совсем другой. Если коротко: будучи вызванной из Modern-приложения, LoadLibrary() не найдёт библиотеки VC++ Redistribution Package, даже если они до этого были успешно установлены.
Первые два способа крайне некрасивы (а без аккаунта администратора и невозможны), третий — сработает, но влияет на глобальную конфигурацию ОС, что тоже может быть чревато последствиями. Так что самый простой вариант — статическая линковка (ключи /MTd и /MT на вкладке Code Generation).
Цифровая подпись
Решив все вопросы с доступом к файлу DLL-ки может показаться, что у нас всё получилось — ProcMon не показывает никаких ошибок доступа. Но инъекция всё равно не работает — DLL-ка не появляется в списке загруженных модулей процесса. Что же пошло не так? На этот вопрос нам даёт ответ просмотр Windows Event Viewer.
Операционная система не хочет загружать нашу DLL-ку, поскольку она не подписана. В этом месте мне стало тревожно, поскольку я уж было подумал, что все модули, загружаемые в Modern-приложение, должны быть подписаны цифровой подписью одного издателя (разработчика). Но, к счастью, это не так. Windows требует от DLL-ки просто наличия валидной цифровой подписи, но не требует её соответствия подписи автора приложения. Т.е. мы можем взять подписанную DLL-ку от Хрома и забросить её в Spartan. Что же делать нам? Получить сертификат и подписывать нашу DLL-ку.
Да, это серьёзно усложняет работу. Но ведь в принципе, если мы разрабатываем нормальный продукт, а не какие-нибудь вирусы\трояны\малвари\кейлоггеры\локеры — у нас не будет проблем с получением сертификата и его использованием для подписи DLL-ки. Вообще, я считаю эту защиту одной из самых серьёзных шагов Microsoft по защите пользовательских данных и изоляции Modern-приложений в песочнице. Фактически от желающего пробросить мостик к приложению требуют предъявить документы и идентифицироваться, а это остановит 99% скрипт-киддисов.
Права доступа на канал связи
Ок, теперь наша DLL-ка внедрена в чужой процесс, она может вешать хуки на разные системные функции, делать что-то полезное, но… Сама она живёт в той же песочнице, что и родительский процесс, то есть ни передать данные «наружу», ни получать команды «извне» она не может, ведь для этого нужно создать канал связи, на который она по умолчанию не имеет прав. Как решать эту задачу я уже отдельно рассказывал вот в этой статье, а здесь просто упоминаю в качестве пункта, о котором важно не забыть.
Windows hook: просто о сложном
Что такое хук?
Что такое хук функций и для чего он нужен? В переводе с английского «hook» — ловушка. Поэтому о назначении хуков функции в Windows можно догадаться — это ловушка для функции. Иными словами, мы ловим функцию и берем управление на себя. После этого определения нам открываются заманчивые перспективы: мы можем перехватить вызов любой функции, подменить код на свой, тем самым изменив поведение любой программы на то, которое нам нужно (конечно, в рамках определенных ограничений).
Целью данной статьи является демонстрация установки хука и его непосредственная реализация.
— Нельзя поверить в невозможное!
— Просто у тебя мало опыта, – заметила Королева. – В твоем возрасте я уделяла этому полчаса каждый день! В иные дни я успевала поверить в десяток невозможностей до завтрака!
Где мне реально пригодились эти знания
Эти знания являются очень узкоспециализированными, и в повседневной практике разработки маловероятно, что они пригодятся, но знать о них, на мой взгляд, крайне желательно, даже если эти знания чисто теоретические. На моей практики же мне пригодились эти знания для решения следующих задач:
• Контроль входящего http-траффика и подмена «взрослого» контента на более безобидный.
• Логирование информации в случае копирования каких-либо файлов с подконтрольной сетевой папки.
• Незначительная модификация кода в проекте, от которого были утеряны исходники (да, и такое тоже случается)
Методы установки хуков
Давайте перейдем от общих фраз к более детальному рассмотрению хуков. Мне известно несколько разновидностей реализации хука:
● Использование функции SetWindowsHookEx. Это весьма простой, оттого и ограниченный, метод. Он позволяет перехватывать только определенные функции, в основном связанные с окном (например, перехват событий, которые получает окно, щелчков мышкой, клавиатурного ввода). Достоинством этого метода является возможность установки глобальных хуков (например, сразу на все приложениях перехватывать клавиатурный ввод).
● Использование подмены адресов в разделе импорта DLL. Суть метода заключается в том, что любой модуль имеет раздел импорта, в котором перечислены все используемые в нем другие модули, а также адреса в памяти для экспортируемых этим модулем функций. Нужно подменить адрес в этом модуле на свой и управление будет передано по указанному адресу.
● Использование ключа реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_Dlls. В нем необходимо прописать путь к DLL, но сделать это могут только пользователи с правами администратора. Этот метод хорош, если приложение не использует kernel32.dll (нельзя вызвать функцию LoadLibrary).
● Использование инъектирования DLL в процесс. На мой взгляд, это самый гибкий и самый показательный способ. Его-то мы и рассмотрим более подробно.
Инъектирование возможно, потому что функция ThreadStart, которая передается функции CreateThread, имеет схожую сигнатуру с функцией LoadLibrary (да и вообще структура dll и исполняемого файла очень схожи). Это позволяет указать метод LoadLibrary в качестве аргумента при создании потока.
Алгоритм инъектирования DLL выглядит так:
1. Находим адрес функции LoadLibrary из Kernel32.dll для потока, куда мы хотим инжектировать DLL.
2. Выделяем память для записи аргументов этой функции.
3. Создаем поток и в качестве ThreadStart функции указываем LoadLibrary и ее аргумент.
4. Поток идет на исполнение, загружает библиотеку и завершается.
5. Наша библиотека инъектирована в адресное пространство постороннего потока. При этом при загрузке DLL будет вызван метод DllMain с флагом PROCESS_ATTACH. Это как раз то место, где можно установить хуки на нужные функции. Далее рассмотрим саму установку хука.
Подход, используемый при установке хука, можно разбить на следующие составные части:
1. Находим адрес функции, вызов которой мы хотим перехватывать (например, MessageBox в user32.dll).
2. Сохраняем несколько первых байтов этой функции в другом участке памяти.
3. На их место вставим машинную команду JUMP для перехода по адресу подставной функции. Естественно, сигнатура функции должна быть такой же, как и исходной, т. е. все параметры, возвращаемое значение и правила вызова должны совпадать.
4. Теперь, когда поток вызовет перехватываемую функцию, команда JUMP перенаправит его к нашей функции. На этом этапе мы можем выполнить любой нужный код.
Далее можно снять ловушку, вернув первые байты из п.2 на место.
Итак, теперь нам понятно, как внедрить нужную нам DLL в адресное пространство потока и каким образом установить хук на функцию. Теперь попробуем совместить эти подходы на практике.
Наше тестовое приложение будет довольно простым и написано на С#. Оно будет содержать в себе кнопку для показа MessageBox. Для примера, установим хук именно на эту функцию. Код тестового приложения:
В качестве инъектора рассмотрим два варианта. Инъекторы, написанные на С++ и С#. Почему на двух языках? Дело в том, что многие считают, что С# — это язык, в котором нельзя использовать системные вещи, — это миф, можно :). Итак, код инъектора на С++:
Теперь тоже самое, но только на С#. Оцените, насколько код более компактен, нет буйства типов (HANDLE, LPVOID, HMODULE, DWORD, которые, по сути, означают одно и тоже).
Теперь самое интересное — код библиотеки, которая устанавливает хуки. Эта библиотека написана на С++, пока без аналога на C#.
Ну и несколько картинок напоследок. До установки хука:
В следующем нашей материале мы постараемся написать код библиотеки, которая устанавливает хуки на C#, т. к. механизм инъектирования управляемого кода заслуживает отдельной статьи.
Хуки — это просто
Хуки — это технология перехвата вызовов функций в чужих процессах. Хуки, как и любая достаточно мощная технология, могут быть использованы как в благих целях (снифферы, аудио\видеограбберы, расширения функционала закрытого ПО, логирование, багфиксинг) так и со злым умыслом (трояны, кряки, кейлоггеры). О хуках уже не раз писали и на Хабре и не на Хабре. Но вот в чём беда — почему-то каждая статья о хуках буквально со второго абзаца начинает рассказывать о «таблице виртуальных функций», «архитектуре памяти» и предлагает к изучению огромные блоки ассемблерного кода. Известно, что каждая формула в тексте снижает количество читателей вдвое, а уж такие вещи — так и вовсе вчетверо. Поэтому нужна статья, которая расскажет о хуках просто. Под катом нет ассемблера, нет сложных терминов и буквально два десятка строк очень простого кода на С++. Если вы давно хотели изучить хуки, но не знали с чего начать — начните с этой статьи.
Реальная задача
Для лучшего понимания того, что мы делаем — поставим себе какую-нибудь реальную задачу. Давайте, например сделаем так, чтобы браузер Firefox при заходе на Хабр писал в своём заголовке «Привет, Хабр!» вместо того, что там пишется сейчас (а сейчас там пришется «*** / Хабрахабр — Mozilla Firefox», где *** — меняется в зависимости от раздела). Да, я знаю, что это можно сделать правкой исходников Firefox, браузерными плагинами, юзерскриптами и еще десятком способов. Но мы в учебных целях сделаем это хуками.
Совсем чуть-чуть теории
Когда Вы запускаете любое приложение — операционная система создаёт его процесс. Грубо говоря, exe-файл копируется в память, далее определяется какие именно библиотеки (dll-файлы) ему нужны для работы (эта информация записана в начале каждого exe-файла), эти библиотеки ищутся (в папке с программой и в системных папках) и загружаются в память процесса. Потом определяется, какие именно функции библиотек использует программа и где они находятся (в какой библиотеке и где именно в этой библиотеке). Строится табличка вида «функция SomeFunction1() — библиотека SomeLibrary1.dll — %адрес_функции_SomeFunction1()%». Когда программе понадобиться вызвать эту функцию — она найдет в своей памяти нужную библиотеку, отсчитает нужный адрес и передаст туда управление.
Суть хукинга — заставить программу поверить, что нужная ей функция находится в другом месте.
Делается это таким образом — мы пишем свою библиотеку SomeLibrary2.dll, в которой будет находится наша функция SomeFunction2(). Далее мы загружаем эту библиотеку в память чужого процесса (в ОС Windows есть специальная функция для этого) и изменяем ту самую табличку, о которой я писал чуть выше, так, чтобы теперь она содержала запись «функция SomeFunction1() — библиотека SomeLibrary2.dll — %адрес_нашей_функции_SomeFunction2()%». Для того, чтобы понять, как вручную сделать всё описанное в этом абзаце, нужно знать весьма прилично всего — как устроена память в Windows, как вызываются функции, как им передаются аргументы и т.д. Это сложно. Ну на самом деле не очень, просто можно обойтись и без этого. Если вам это нужно — почитайте какую-нибудь продвинутую статью (а хоть бы из тех, что указаны в начале). Мы пойдем другим путем — используем готовую библиотеку Microsoft Detours, которая сделает всю грязную работу за нас.
Пару слов о Microsoft Detours
Проста в изучении и использовании
Весьма эффективна
Хорошая документация
Содержит много примеров в исходниках
Разработана Microsoft — неплохо «дружит» с ОС
Бесплатна для исследовательских целей и некоммерческих проектов
Не требует знания ассемблера
Закрыта
Стоит приличных денег для коммерческого использования или х64-архитектуры
В целом, я бы посоветовал начинать изучение хуков именно с Detours — если это будет всего лишь вашим разовым развлечением, то этого вполне хватит, у вас быстро всё получится и вам понравится. Если же хуки понадобятся в серьёзном проекте — вы легко переключитесь на бесплатные и открытые (но чуть более сложные) библиотеки типа mhook, купите Detours или напишете свой велосипед (для последних двух решений нужны весьма веские причины).
О том где взять и как собрать Detours я писал вот тут.
Хитрый план
Куда ставить хук
Переходим в Firefox, открываем Хабр, дожидаемся изменения заголовка на нужный и возвращаемся в Api Monitor чтобы остановить мониторинг. Скорее всего, вы будете удивлены количеством вызванных функций — их могут быть сотни тысяч буквально за несколько секунд мониторинга. А мы ведь еще и следим далеко не за всем. Да-да, это всё реально происходит внутри безобидного открытия всего одного сайта в браузере! А вы еще жалуетесь, что эта пара секунд — слишком долго. 🙂
Найти нужную нам функцию поможет поиск по вкладке с результатами мониторинга. Вбиваем в поиск «WM_SETTEXT» и убеждаемся, что действительно имеются вызовы функции SendMessageW с этим параметром — с высокой вероятностью это и есть установка заголовка окна. Обратите внимание на «W» в конце названия функции — оно означает, что используется её юникодная версия. Для установки хуков важно знать точное имя подменяемой функции и теперь мы его знаем.
Делаем свою библиотеку
4. Открываем свойства проекта и на вкладке настроек линкера добавляем в поле Additional Dependencies значение «C:\Program Files\Microsoft Research\Detours Express 3.0\lib.X86\detours.lib». Внимание, у вас путь может быть другой — смотря куда установили библиотеку Detours.
Давайте разберем исходник. В начале мы подключаем заголовочные файлы Windows (чтобы пользоваться функцией SendMessageW) и Detours (чтобы иметь возможность ставить\снимать хуки).
В сложной на первый взгляд строке №3 мы всего лишь сохраняем реальный указатель на функцию SendMessageW в переменную TrueSendMessageW. Это нам понадобиться для двух целей:
Функция DllMain вызывается операционной системой в определенных случаях — например, в моменты аттача\детача библиотеки к процессу. Тут тоже всё просто. В момент аттача нам нужно установить хуки, в момент детача — снять. Библиотека Detour требует делать это транзакциями, и в этом есть смысл — представьте себе что будет, если сразу несколько желающих захотят поставить хуки в один процесс. Самое важное в этом коде это строка
Именно она заставляет процесс «поверить» что теперь вместо настоящей функции SendMessageW нужно вызывать нашу MySendMessageW. Ради этой строки всё и затевалось. Если кому интересно, однажды я писал аналог этой функции вручную. С учетом всех возможных комбинаций типов функций и архитектур это заняло у меня несколько недель. Вы вот только что их сэкономили — поздравляю.
Вступление
Для начала пару слов, о том что такое в целом хуки (hooks) и для чего они могут быть нужны. Git «из коробки» предоставляет инструмент, который умеет запускать ваши скрипты при наступлении какого-либо события (к примеру пуш на сервер и т.п.)
Установка
Установим необходимые зависимости:
Выскажу свое мнение по поводу flake-8 и линтеров в целом. Если у вас уже большой проект с кучей legacy кода, то можете линтеры смело удалять. Затраты которые будут потрачены на «приведение к идеалу», начальство не оценит. Линтеры ставим для новых (и небольших) проектов. Повторюсь, это лично мое мнение, никому его не навязываю.
Интеграция в среду
Заходим в корневой каталог среды разработки и выполняем следующие команды
Тесты
Помимо проверки и форматирования кода мы будем выполнять тесты на этапе создания коммита. Для этого мы будем использовать pytest (https://docs.pytest.org/en/latest/) и настроим его для наших нужд.
В корневом каталоге нашей среды создадим файл pytest.ini
Далее создадим папку tests и поместим туда следующие файлы
test_example_without_db.py, test_example_with_db.py
Для удобства настроим тесты таким образом, чтобы можно было использовать текущую базу данных (к примеру копию базы данных с боевого сервера), а не создавать каждый раз новую.
Простой тест test_example_without_db.py
В простых тестах мы можем подключить например webbot и обходить узлы нашей системы, чтобы автоматизировать ручной труд тестировщика.
Тест с использованием базы данных test_example_with_db.py
Пример довольно искусственный и создан исключительно для данной заметки, но тем не менее он позволяет нам обратиться к текущей базе данных, и провести сложные тесты, которые выходят за рамки ручного тестирования.
Чтобы подключить тесты нам потребуется shell script в корневом каталоге среды, который мы назовем tests.sh:
Его содержание весьма очевидное, но вы можете заметить что активация виртуального окружения явным образом прописана в коде. Это может быть неудобно, если ваша команда ведет разработку на разных рабочих станциях (к примеру кто развернул среду на локальной машине, а кто-то разрабатывает на сервере).
Создаем коммит
Теперь осталось создать коммит и посмотреть как это работает
Коммит теперь создается в «два этапа». На первом этапе хуки выполняют форматирование кода, поэтому после их работы нам нужно просто «повторить» команды.
Введение в React Hooks
Мотивация стоящая за Hooks
Хотя компоненто-ориентированная архитектура позволяет нам повторно использовать view в нашем приложении, одна из самых больших проблем, с которыми сталкивается разработчик, заключается в том, как повторно использовать логику, находящуюся в state, между компонентами. Когда у нас есть компоненты, которые имеют сходную логику состояния, нет хороших решений для переиспользования компонентов, и это иногда может привести к дублированию логики в конструкторе и методах жизненного цикла.
Чтобы решить эту проблему, обычно используют:
Hooks нацелены на решение всех этих проблем, позволяя вам писать функциональные компоненты, которые имеют доступ к state, context, методам жизненного цикла, ref и т. д., без написания классов.
Hooks в Alpha
Прежде чем мы погрузимся, важно упомянуть, что разработка Hooks API еще не завершена.
Кроме того, официальная документация очень хороша, и мы рекомендуем ее прочитать еще и потому, что в ней расширенно описана мотивация, стоящая за введением Hooks.
UPD Оригинальная статья, перевод которой вы читаете была написана еще в то время, когда это API было в alpha тестировании, на данный момент React Hooks официально готовы к использованию. Необратимые изменения, привнесенные в релиз (по сравнению с альфой) можно посмотреть внизу статьи или в релизных заметках.
Как Hooks соотносятся с классами
Напомним, что при написании классов компонентов нам часто необходимо:
С помощью React Hooks мы можем воспроизвести аналогичное поведение в функциональных компонентах:
Для использования Hooks необходима последняя версия React
Вы можете начать работу с Hooks прямо сейчас, сменив значение react и react-dom в вашем package.json на «next».
Пример useState() Hook
State является неотъемлемой частью React. Он позволяет нам объявлять переменные, которые содержат данные, которые, в свою очередь, будут использоваться в нашем приложении. С помощью классов state обычно определяется следующим образом:
В вышеприведенном блоке кода, мы начинаем с импорта useState из React. UseState — это новый способ использования возможностей, которые раньше могло предложить this.state.
Затем обратите внимание, что этот компонент является функцией, а не классом. Интересно!
Чтение и запись state
Внутри этой функции мы вызываем useState для создания переменной в state:
useState используется для объявления переменной state и может быть инициализирован любым типом значения (в отличие от state в классах, который должен быть объектом).
Затем мы применяем их как обработчики событий на кнопках во view:
React отслеживает state
Когда нажимается кнопка «On», Вызывается функция setOn, вызывающая setLight(1). Вызов setLight(1) обновляет значение light для следующего рендера. Это может показаться немного волшебным, но React отслеживает значение этой переменной и будет передавать новое значение, когда происходит ре-рендер этого компонента.
Затем мы используем текущее состояние (light), чтобы определить, должна ли лампа быть включена или нет. То есть, мы устанавливаем цвет заливки SVG в зависимости от значения light. Если light равен 0 (выкл.), То для fillColor установлено значение # 000000 (а если равен 1 (включено), fillColor устанавливается на # ffbb73).
Multiple States
Хотя мы не делаем этого в приведенном выше примере, вы можете создать несколько state, вызвав useState более одного раза. Например:
ПРИМЕЧАНИЕ.
Существуют некоторые ограничения при использовании hooks, о которых вы должны знать. Самое главное, вы должны вызывать hooks только на верхнем уровне вашей функции. См. «Правила hooks» для получения дополнительной информации.
Пример useEffect() Hook
Используя useEffect() Hook, React знает, что вы хотите выполнить определенное действие после рендеринга.
Давайте посмотрим на пример ниже. Мы будем использовать useEffect() для вызова API и получения ответа.
В этом примере кода используются как useState, так и useEffect, и это потому, что мы хотим записать результат вызова API в state.
Получение данных и обновления state
Чтобы «использовать эффект», нам нужно поместить наш action в функцию useEffect, то есть мы передаем «action» эффект как анонимную функцию, как первый аргумент useEffect.
В примере выше мы обращаемся к API, которое возвращает список имен. Когда возвращается response, мы конвертируем его в JSON, а затем используем setNames(data) для установки state.
Проблемы с производительностью при использовании Effects
Однако стоит сказать еще кое-что об использовании useEffect.
Первое, о чем нужно подумать, это то, что по умолчанию наш useEffect будет вызываться на каждом рендере! Хорошей новостью является то, что нам не нужно беспокоиться об устаревших данных, но плохая новость заключается в том, что мы, вероятно, не хотим делать HTTP-запрос для каждого рендеринга (как в этом случае).
В приведенном выше примере кода обратите внимание, что мы передаем пустой массив в качестве второго аргумента. Это мы говорим React, что мы хотим только назвать этот effect при монтировании компонента.
Кроме того, как и функция useState, useEffect позволяет использовать несколько экземпляров, что означает, что вы можете иметь несколько функций useEffect.
Пример useContext() Hook
Контекст в React- это способ для дочернего компонента получить доступ к значению в родительском компоненте.
Чтобы понять необходимость context: при создании React приложения вам часто нужно передавать значения с верха вашего дерева React вниз. Не используя context, вы передаете props через компоненты, которым не обязательно о них знать.
Передача props вниз по дереву «несвязанных» компонентов ласково называется props drilling.
React Context решает проблему props drilling, позволяя вам делиться значениями через дерево компонентов, с любым компонентом, который запрашивает эти значения.
useContext() упрощает использование context
С useContext Hook использование context стает проще, чем когда-либо.
Функция useContext() принимает объект сontext, который изначально возвращается из React.createContext(), а затем возвращает текущее значение контекста. Давайте посмотрим на пример ниже.
В приведенном выше коде context JediContext создается с использованием React.createContext().
Мы используем JediContext.Provider в нашем App компоненте и устанавливаем там значение «Luke». Это означает, что любой компонент, которому нужно получить доступ к context теперь сможет считать это значение.
Чтобы прочитать это значение в функции Display(), мы вызываем useContext, передавая аргумент JediContext.
Затем мы передаем объект context, который мы получили из React.createContext, и он автоматически выводит значение. Когда значение провайдера будет обновляться, этот Hook автоматически сработает с последним значением context.
Получение ссылки на context в более крупном приложении
Выше мы создали JediContext в рамках обоих компонентов, но в более крупном приложении Display и App будут находиться в разных файлах. Поэтому, если у вас похожая ситуация, вам может быть интересно: «Как мы получаем ссылку на JediContext между файлами?»
Ответ заключается в том, что вам нужно создать новый файл, который экспортирует JediContext.
Например, у вас может быть файл context.js, который содержит что-то вроде этого:
и потом в App.js (и Display.js) вы должны написать:
Пример useRef() Hook
useRef() и формы с input
Давайте посмотрим пример использования useRef() hook.
В приведенном выше примере мы используем useRef() в сочетании с useState(), чтобы отрендерить значение input в тег p.
Ref создается в переменной nameRef. Затем переменную nameRef можно использовать в input, задав как ref. По существу, это означает, что теперь содержимое поля ввода будет доступно через ref.
Кнопка отправки в коде имеет обработчик события onClick, называемый submitButton. Функция submitButton вызывает setName (созданный через useState).
Как мы уже делали с использованием hookState, setName будет использоваться для установки state name. Чтобы извлечь имя из тега input, мы читаем значение nameRef.current.value.
Еще одно замечание относительно useRef заключается в том, что его можно использовать больше, чем атрибут ref.
Использование пользовательских Hooks
Одной из самых крутых особенностей Hooks является то, что вы можете легко делиться логикой между несколькими компонентами, создавая собственный Hook.
В приведенном ниже примере мы создадим пользовательский setCounter() Hook, который позволяет нам отслеживать состояние и предоставлять настраиваемые функции обновления state!
В приведенном выше блоке кода мы создаем функцию useCounter, которая хранит логику нашего hook.
Обратите внимание, что useCounter может использовать другие Hooks! Начнем с создания нового состояния Hook через useState.
Затем мы определяем две вспомогательные функции: increment и decrement, которые вызывают setCount и соответственно корректируют текущий count.
Наконец, мы возвращаем ссылки, необходимые для взаимодействия с нашим Hook.
В: Что происходит, возврат массива с объектом?
О: Ну, как и большинство вещей в Hooks, соглашения API еще не завершены. Но то, что мы делаем здесь, возвращает массив, где:
Тем не менее, вы можете вернуть все, что захотите, из своего кастомного Hook.
В приведенном выше примере мы используем increment и decrement как обработчики onClick, в нашем view. Когда пользователь нажимает кнопки, счетчик обновляется и повторно отображается (как myCount) во view.
Написание тестов для React Hooks
Чтобы написать тесты для hooks, мы будем использовать библиотеку для тестирования react-testing-library.
С тестированием hooks еще не все понятно. В настоящее время вы не можете протестировать hook изолированно. Вместо этого вам нужно прикрепить свой hook к компоненту и протестировать этот компонент.
Итак, ниже мы будем писать тесты для наших Hooks, взаимодействуя с нашими компонентами, а не с Hooks напрямую. Хорошая новость заключается в том, что наши тесты будут выглядеть как обычные тесты React.
Тестирование useState() Hook
Давайте посмотрим пример написания тестов для useState Hook. В приведенном выше уроке мы тестируем больше вариаций используемого выше примера useState. Мы будем писать тесты, чтобы убедиться, что нажатие кнопки «Off» Устанавливает состояние в 0 и нажатие кнопки «On» Устанавливает состояние в 1.
В вышеприведенном блоке кода мы начинаем с импорта некоторых хелперов из react-testing-library и тестируемого компонента.
Тест проверяет, что, если нажимается onButton, значение state устанавливается в 1, а при нажатии на offButton state равен 1.
Тестирование useEffect() Hook
В этом примере мы будем писать тесты, чтобы добавить товар в корзину, используя useEffect Hook. Количество элементов также сохраняется в localStorage. Файл index.js в CodeSandbox ниже содержит фактическую логику, используемую для добавления элементов в корзину.
Мы будем писать тесты, чтобы убедиться, что обновление количества элементов корзины также отражено в localStorage, и даже если страница перезагрузилась, количество элементов корзины все еще остается прежним.
В функции, подтверждающей прохождение теста мы сначала устанавливаем cartItem в localStorage равным 0, что означает, что количество элементов корзины равно 0. Затем мы получаем как container так и rerender из компонента App через деструктурирование. Rerender позволяет нам имитировать перезагрузку страницы.
Затем мы получаем ссылки на кнопки и тег p, который отображает текущее значение корзины и устанавливает их в переменные.
Как только это будет сделано, тест затем имитирует щелчок на addButton и проверяет, является ли текущий счетчик корзины равным 1 и перезагружает страницу, после чего, если он проверяет, установлено ли значение localStorage, cartItem, равным 1. Затем он моделирует нажатие на resetButton и проверяет, установлено ли текущее количество элементов корзины равным 0.
Тестирование useRef () Hook
В этом примере мы будем тестировать useRef Hook, и мы будем использовать исходный пример useRef, приведенный выше в качестве основы для теста. UseRef используется для получения значения из поля ввода, а затем устанавливает значение state. Файл index.js в CodeSandbox ниже содержит логику ввода значения и его отправки.
В функции, утверждающей прохождение теста мы устанавливаем переменные в поле input, тег p, который отображает текущее значение ref, и кнопку отправки. Мы также устанавливаем значение, которое мы хотели бы ввести в поле ввода, для переменной newName. Это будет использоваться для проверки в тесте.
Метод fireEvent.change используется для ввода значения в поле input, и в этом случае используется name, сохраненное в константе newName, после чего нажимается кнопка отправки.
Затем тест проверяет, соответствует ли значение ref после нажатия кнопки значение newName.
Наконец, вы должны увидеть «Нет падений тестов, поздравляем!» сообщение в консоли.
Реакция сообщества на Hooks
С того момента как представили React Hooks, сообщество было в восторге от этой фичи, и мы видели множество примеров и примеров использования React Hooks. Вот некоторые из основных:
Различные типы hooks
Существуют различные типы hooks, которые вы можете начать использовать в своем React приложении. Они перечислены ниже:
Будущее hooks
Тем не менее, Hooks все еще являются экспериментальной функцией, и команда React неоднократно предупреждала, что API может быть изменен. Считайте что вы предупреждены.
Что означает для классов появление Hooks? Как сообщает команда React, классы все еще остаются, они являются огромной частью кодовой базы React и, скорее всего, будут еще какое-то время.
У нас нет планов осуждать классы. В Facebook у нас есть десятки тысяч компонентов, написанных классами, и, как и вы понимаете, мы не собираемся переписывать их. Но если сообщество React одобрит Hooks, нет смысла иметь два разных рекомендуемых способа записи компонентов — Дэн Абрамов
Хотя конкретный API-интерфейс Hooks является экспериментальным сегодня, сообщество одобряет идею Hooks, поэтому я думаю, что они останутся с нами надолго.