React стал одной из ведущих библиотек для фронтенд-разработки. Дополнительные продукты, такие как Next.js или Remix, позволяют разработчикам создавать полнофункциональные веб-приложения с помощью React. Довольно удивительная вещь.
React использует возможности Javascript XML, расширения синтаксиса, которое сочетает в себе HTML и логику рендеринга. Это позволяет нам разбивать сложные веб-сайты на многоразовые компоненты размером с укус. Одной из фундаментальных концепций React являются «реквизиты», сокращение от свойств. Реквизиты — это основной способ передачи информации и функций между компонентами, составляющими сайт. Это похоже на техническую игру в телефон, где недопонимание практически невозможно. Но! Недопонимание и дезорганизация произойдут на любом языке программирования, если запрограммировать его безответственно. В этой статье мы рассмотрим некоторые общие принципы ответственного использования реквизита.
Принципы ответственного прохождения
1. Имейте стандартизированные типы реквизита. Реквизит должен вести себя предсказуемо. Этот принцип распространяется на всю экосистему React. Если типы данных свойств четко определены, ошибки будет легче отлавливать, а кодирование может выполняться намного быстрее.
Решение. Используйте встроенную функцию React TypeCheck для проверки типов передаваемых свойств. Определяя и проверяя типы свойств, вы можете убедиться, что передаются правильные типы данных. Документацию по TypeCheck можно найти здесь.
2. Избегайте чрезмерного детализации реквизита. Детализация реквизита – это передача реквизита через несколько уровней компонентов в приложении. Что отличает это от обычной передачи пропса, так это то, что пропс не используется большинством передающих компонентов. Уровень до того, как это достигнет просверливания винтов, полностью субъективен, но проблемы иерархии компонентов с просверленными отверстиями скоро станут ясными. Пропеллерное бурение быстро превратит код в неподдающегося сопровождению бегемота. Каждый реквизит, который необходимо обновить, будет означать обновление всех связанных компонентов. Ошибки также будет намного сложнее отловить, поскольку каждый компонент очень сильно связан друг с другом. С опорным бурением приложение теряет свой модульный характер.
Решение. Простая альтернатива — React Context API и хук useContext, который позволяет глобально обмениваться данными без использования реквизитов сверху вниз. Это полезный ресурс для реализации Context API.
3. Документация здравого смысла: свойства с именами «xxyx» или «prop» могут затруднить отладку и совместную работу, если вам приходится останавливаться каждые пять минут, чтобы объяснить свойство или найти его исходный компонент. Это важный принцип проектирования, который применим не только к React, но и ко всей разработке программного обеспечения.
Решение. Используйте понятные имена и комментарии в коде, поясняющие функции и компоненты. Попробуйте подумать о том, как ваш код будет выглядеть для тех, кто его раньше не видел. Точно ли имена переменных и пропсов описывают их назначение? Будьте хорошим товарищем по команде и разработчиком и программируйте на простом английском языке.
4. Ограничьте мутацию Prop:Props предназначены только для чтения в React. Цепь логики и ожидаемого поведения становится намного сложнее предсказать, если реквизиты меняются повсюду.
Решение.Используйте хук useState или функции обратного вызова в ситуациях, когда значение необходимо изменить. Это гарантирует, что логика аккуратно заключена. Дополнительную информацию о хуках состояния можно найти здесь.
Вывод.Ответственное использование props жизненно важно для создания удобного в сопровождении и модульного приложения React. Следуя лучшим практикам, таким как проверка реквизитов, избегание чрезмерного детализации реквизитов, оставаясь хорошо документированными и ограничивая мутацию реквизитов, мы можем создавать более надежный и понятный код для проблем завтрашнего дня.
