Ваш код React отстой, и вот почему

Ваш код React отстой, и вот почему

TL;DR Вы должны использовать TypeScript

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

React — это фреймворк

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

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

Почему это недоразумение может сделать мой код отстойным? Он сужает пул опций, ограничивая вас известными библиотеками, такими как react-router-dom, хотя они могут быть не правильным выбором для каждого проекта.

TypeScript означает медленную разработку

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

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

Страшный tsconfig дума, необходимость переименовывать файлы в .ts/.tsx и часто бороться с тем, чтобы все работало вместе. Интерфейсы, типы, дженерики — весь этот синтаксический сахар TypeScript может потребовать времени для написания, но обеспечивает уровень безопасности и структуры, от которых могут выиграть даже небольшие проекты.

Мне не нужен TypeScript в моих собственных проектах. Я действительно ненавижу это утверждение, так как оно не рисует общей картины. Что, если вы покинете этот проект и через несколько месяцев/лет захотите его продолжить? Что, если другие присоединятся к проекту и часами пытаются понять логику? TypeScript заставляет вас в будущем благодарить вас за легкость возвращения в проект или подключение других при меньшем количестве поломок.

Эффекты везде

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

Я сократил только две ситуации, когда useEffect необходим, если вы извлекаете данные асинхронно или вам нужен доступ к DOM для настройки прослушивателей событий или временных шкал анимации (в этом случае вам может понадобиться useLayoutEffect) .

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

useState запускается только один раз, любые изменения начального значения не вызовут обновления пользовательского интерфейса, поэтому вы добавляете этот лишний useEffect для прослушивания изменений свойства defaultValue, но это уже не defaultValue, верно?

Итак, мне нужно удалить все useEffects, которые я использую в своем приложении? Нет, часто бывает сложно обнаружить опасные побочные эффекты, к счастью, есть решение путем добавления react-hooks/rules-of-hooks правила Эслинта.

Запоминать все вещи? Ни за что.

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

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

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

Значит, мне нужно запоминать все? Мое утверждение и подход более консервативны, если переменная происходит от простой логической операции (например, && или иной), добавление useMemo не сильно улучшит и не раздует кодовую базу, но для более сложных вычислений, у которых есть шанс повториться через те же значения, считаю обязательным.

Кэширование? ВТФ.

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

Давайте будем честными, именно так вы извлекаете данные из API?

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

Готовый отличный уровень кэширования, отличная поддержка TypeScript и великолепный API-интерфейс. Это делает ваши запросы к API надежными, декларативными и простыми для понимания.

Да, но это означает, что я должен писать типы для каждого ответа/запроса… Не обязательно, такие инструменты, как Orval, могут помочь генерировать типы из схем swagger или даже делиться ими между сервером и клиентом с помощью trpc.

создать-реагировать-приложение — это GOAT

Настройка PostCSS, Webpack и всех этих конфигураций требует больших усилий, поэтому вы, вероятно, используете приложение create-react-app для каждого проекта, еще хуже, вы можете использовать craco и застрять на CRA 4.

Это отличные инструменты для начала работы с React и скрытия хаоса конфигурации, которым является вся среда разработки JavaScript, но они часто создают неприятные пограничные случаи, когда миграция с приложения create-react-app является единственным вариантом.

Необходимость настройки Webpack в CRA невозможна без извлечения и попадания в столпотворение конфигурации. Не будем забывать, что это означает, что вы застряли с CSR (рендеринг на стороне клиента), поэтому никакой прирост производительности SSR/SSG невозможен.

Почти нет обстоятельств, при которых CRA является правильным выбором для в основном динамических сайтов, использующих Vercel + Nextjs (create-t3-app — настоящий GOAT) или даже Remix всегда лучше в сценариях SSR с часто меняющимися данными.

Если SSG является подходящей стратегией с редко изменяющимися источниками данных, такими как блоги или целевые страницы, Astro — это настоящий зверь, предлагающий свою собственную структуру (React, Vue и т. д.), но поставляемую 0 или столько JavaScript, сколько вам нужно.

Я даже не собираюсь начинать использовать Vite вместо webpack, поскольку он гораздо более эффективен и удобен в настройке (по моему непроверенному мнению), то же самое я могу сказать о выборе Vitest вместо Jest.

Значит, мне больше не следует использовать CRA? В 99% случаев нет реальной причины начинать новый проект с его помощью, если CSR — единственный способ, используйте вместо этого что-то вроде create-vite.

Теперь ваш код может быть менее отстойным

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

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

У вас есть вопросы или предложения? Не стесняйтесь обращаться! 🚀. Если вы хотите быть в курсе моих будущих статей, подписывайтесь на меня в Medium или Twitter.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord . Заинтересованы в хакинге роста? Ознакомьтесь с разделом Схема.