Ихрь постит в уютный бложик: заметки с тегом react

How to inline TailwindCSS styles to SSR NextJS

Wed, 04 Oct 2023 11:54:42 +0300

By default, NextJS may not include Tailwind styles in the SSR build, and with disabled JavaScript, your site may look ugly like pure HTML.

To fix this, you need to install the critters package.

npm install critters

And enable optimizeCss rule in next.config.js.

experimental: {
    optimizeCss: true,
},

Source: next.js#12868.

Как babel-плагин замедлил приложение в 2 раза

Thu, 04 Mar 2021 19:11:13 +0300

TL;DR: в @babel/plugin-transform-classses есть баг, который вызывает падение перформанса.

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

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

С ними в проекте недавно была проведена работа по дедубликации лок-файла и дерева зависимостей, вместе с чем обновились некоторые библиотеки. Минус 7000 строк лока, разбор проблемы обещал быть веселым.

Проблему искал сначала мой коллега, затем я. Не знаю, сколько времени на это было потрачено, но причиной оказался один плагинчик — @babel/plugin-transform-classses. Откатил версию, зафиксировал ее, и все заработало.

Из-за отсутствия зацепок исследование проводилось методом исключения, благо, модули babel были близко к началу очереди.

Как оказалось, с 1 апреля 2020 года в репозитории есть репорт этой проблемы — babel#11356.

Сейчас разбираться, че там внутри плагина поменялось мне лень, конечно, но когда-нибудь обязательно покопаю, когда-нибудь.

В нашем случае замедление было в среднем в 2+ раза. Некоторым повезло меньше, после обновления Angular можно поймать и более ощутимые просадки.

В очередной раз поймал себя на мысли, что в 2021 году babel уже не нужен. Пора начать выпиливать его из проектов!

Сейчас придумал теорию заговора, что babel так с адептами ООП борется просто.
Как там было? Если хочешь, чтобы перестали использовать deprecated метод, добавь в него sleep.

Ошибки state-менеджмента React-компонентов

Mon, 15 Jun 2020 19:01:52 +0300

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

Когда были классовые компоненты, многие хранили в стейте вообще все, даже какие-то служебные флаги, которые можно было бы в this записать, и которые на рендер компонента никак не влияют.

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

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

Парочка самых распространенных, что я видел: Эффект, который слушает проп и обновляет в след за ним стейт без каких-либо преобразований. Что-то вроде такого:

const component = ({ prop }) => {
  const [savedProp, setSavedProp] = useState(null);

  useEffect(() => {
    setSavedProp(prop);
  }, [prop]);
};

Больше логики никакой, никаких подводных камней. Мало того, что можно было бы прямо в useState прокидывать проп, так все гораздо проще — можно было бы использовать сам этот проп, вместо его сохранения в стейт! Вероятно, там когда-то был какой-то процессинг, может быть, какие-то условия, но больше этого нет, зато есть несколько ненужных обновлений компонента.

Эффект, который слушает изменения стейта, чтобы… вызвать коллбэк.

const component = ({ prop, onPropChange }) => {
  const [savedProp, setSavedProp] = useState(null);

  useEffect(() => {
    onPropChange(savedProp);
  }, [savedProp]);

  return (
    <Child prop={prop} onPropChange={setSavedProp} />
  )
};

Тут все вроде бы тоже понятно, но стейт не используется ни для чего, кроме триггера коллбэка. Правильнее прокинуть просто коллбэк и… все, а не триггерить несколько апдейтов просто так. Так мало того, часто забывают что-то еще в зависимости эффекта прокинуть, и он работает совсем не так, как должен.

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

UI library based on Chakra-UI bundling

Thu, 09 Apr 2020 18:49:15 +0300

Recently I tried to build some UI components library that based on Chakra-UI. At first my library didn’t contain react components and compiled using typescript and it worked perfectly. But after I added React components based on Chakra-UI and migrated build to webpack, I’ve got the next error from react hooks that were called inside Chakra-UI hooks such as useTheme:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.
By the way, Chakra-UI repository has this issue about this error - ((https://github.com/chakra-ui/chakra-ui/issues/495 #495)).

What is the reason for this error? useTheme hook and Chakra-UI library in whole use react library. As a result library imports react and react-dom. When webpack bundling your library that includes Chakra-UI, it includes react and react-dom to bundle of your library. In brief, you import react to your project, also you import your library with Chakra-UI that contains react too, as a result — you have at least two React copies. And in fact, it’s incorrect hook call.

How to fix it? Use only single react instance in your app. If you’re using webpack you can mark react and react-dom libraries as external libraries for your components library:

externals: {
  // mark "react" and react-dom as external packages that will import using commons
  react: 'commonjs react',
  'react-dom': 'commonjs react-dom'
},
output: {
  path: path.resolve('./'),
  libraryTarget: 'commonjs2', // set library target
  filename: '[name].js',
  library: '',
}

Now bundle of your library doesn’t contain react and react-dom. We marked libraries as external and have pure require calls but doesn’t have library in bundle:

/***/ "react":
/*!************************!*\
  !*** external "react" ***!
  \************************/
/*! no static exports found */
/***/ (function(module, exports) {
  module.exports = require("react");
/***/ }),

/***/ "react-dom":
/*!****************************!*\
  !*** external "react-dom" ***!
  \****************************/
/*! no static exports found */
/***/ (function(module, exports) {
  module.exports = require("react-dom");
/***/ })

This way also can help you if you’re using hooks and creating your own UI library without Chakra-UI.

NextJS, первый взгляд

Fri, 28 Feb 2020 18:45:08 +0300

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

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

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

Казалось бы, роутинг должен быть сильнее всего проработан в фреймворке такого типа, но то ли я не понял, как им правильно пользоваться, то ли оно как-то странно сделано. Ладно, со ссылками пришлось повозиться, ибо в одном случае href — тот url, на который непосредственно идет редирект, а в другом случае — slug страницы, который я определил в роутере, а непосредственно ссылку прокидывать нужно в проп as.

Но вот если пушить что-то в url с динамическим роутом, то получается что-то странное. Пушу не явный конечный url, а slug описанный в роутинге, нужна квери-стринга? Ок, квери можно прокинуть в отдельный объект, они даже до чилда долетят, но вот в url они не попадут, бери ручками и прокидывай.

Тут у меня прямо явный диссонанс:

Ожидание: сейчас я в метод пуш прокину объект квери и текущий адрес — хоба, квери обновлен, строка адреса хранит состояние, все счастливы.
Реальность: прокидываю реальный адрес, прокидываю шаблон адреса, прокидываю квери-объект, новый полный адрес вместе с квери, который сам леплю чем-то, — тоже все счастливы, конечно, но большей ценой.

Действий немного, но хотелось бы каких-то изящных абстракций из коробки, а не руками их делать.

Почему ломаются React-хуки

Fri, 13 Sep 2019 18:18:37 +0300

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

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

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

Втащили библиотеку, заюзали их хуки и… все сломалось, вместо приложения красовалась ошибка:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.

Конечно, первым делом я перешел по ссылке, проверил версии React’а и всего остального, проверил корректность использования хуков, но все мои исследования пользы не принесли, все было корректно, тогда я пошел шерстить GitHub в поисках решений и источников проблемы.

Из первого попавшегося react#15315, там виновных нашли сразу кучу, и неправильное использование роутера, и HtmlWebpackPlugin, и вызов в HoC’е, а в react-dropzone#821 вообще оказалось, что все ломали observer’ы из mobx.

Мой случай похож, хуки ломались из-за использования такой утилиты, как why-did-you-update, которая, к слову, довольно долго жила во многих проектах без проблем, а тут вот всплыло. Соответственно, чтобы поправить работу приложения ни осталось ничего, кроме того, что убрать вызов утилиты.

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

React Higher-Order Components

Mon, 24 Jul 2017 17:08:24 +0300

Несколько расстраивает, что сюда ничего не пишу, так что буду вкидывать какие-то заметки и кусочки кода.
Начнём с простого и понятного примера Higher-Order Components в React.

Enhance.jsx

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello, World!!!' });
  }
  render() {
    return <ComposedComponent {...this.props} data={this.state.data} />;
  }
};

HigherOrderComponent.jsx

import { Enhance } from "./Enhance";

class MyComponent {
  render() {
    if (!this.data) return <div>React loading...</div>;
    return <div>{this.data}</div>;
  }
}

export default Enhance(MyComponent);