Комментарии 13
Какой-то такой этап, реакт уже проходил года 4 или 5 тому назад, то есть где-то между эпохами классов и хуков.
Одна из проблем с ним это стек-трейсы при отладке - дерево вызовов перестаёт отражать иерархию вложенности компонентов, уводя в бесполезные врапперы.
Уже исправляю видимость состояния в ReactDevtools и показ названия компонента в древе
Это ломает просмотр состояний компонентов в ReactDevtools, но такова цена производительности. - дальше не стал читать
А что мешает взять какой нибудь стм (Mobx) и там все это дело написать?
"Лично мне не нравятся повсеместные стрелочные функции и this" - странный аргумент для меня. Написание method = () => вместо method() и this сподвигли на то, чтобы выпустить новую утилиту, которая превращает функциональные компоненты Реакта в SolidJS-like? Но классы ведь придуманы для удобной организации кода. Чтобы не была функция из 5000 строк и 50 вложенных функций смешанного назначения, а были удобно организованные слои - хендлеры пользовательский событий, реакции, состояние, геттеры подготовленных данных, которые схлопываются IDE и гармонично могут использовать друг друга без заботы о hoisting, когда const a = 1 объявлена ниже, чем используется.
И в целом функциональные компоненты для меня очень неудобны как раз отсутствием this - в каждый хук надо передавать состояние, результат других хуков и при необходимости ссылки на них, в данной статье эти кейсы не показаны, но в реальности может быть myCustomHook(...10 params). В классах этой проблемы нет благодаря this и тому, что каждый метод имеет доступ ко всем другим методам, геттерам и состоянию.
Думаю, будущее все-таки за классами, и то что разработчики реакта придумали с раздутыми функциями с необходимостью ручного проброса одного в другое, скрытыми хранилищами и ручной заботой о равенстве по ссылкам уйдет в прошлое. Хотя afc решает часть проблем, остальные остаются.
Мне самому также не нравится что разработчики реакта смотрят в сторону хуков. Не будь у них проблем - не было бы этой статьи.
Использовать классы или функции это выбор каждого, поэтому хотелось бы видеть их одинаковую поддержку и развитие. Но что есть то есть..
Чтобы понять логику разработчиков, надо смотреть языки где есть поддержка функционального программирования - не такая ущербная как в JS, но и не такая упоротая как в Haskell. Например OCaml.
Насколько я понимаю, цель дать разработчикам инструмент, позволяющий описывать интерфейс декларативно, но используя для этого лишь стандартные языковые конструкции JS. Без компромисса в виде метаязыка JSX все равно не получилось, но на то есть причины. В остальном они сначала долго пытались приспособить под задачу синтаксис классов, но потом перешли на функции.
Не в последнюю очередь потому, что народ продолжал по привычке думать в стиле ООП и сохранять состояние в свойствах объекта. Переубедить полмира это невозможно, а функции создают естественные ограничения.
А как быть со случаями, когда пропы компонента меняются и коллбек должен об этом знать? Создавать в замыкании переменные, через которые прокидывать пропы?
Не пойму я никак чем это все отличается от
var el = <Component props={any}
Или React.memo
Или какой там уровня кэша...
На сам деле не понятно что за проблема у вас
Если в переиспользуемом компоненте есть сложная логика, то решая проблему оптимизации без доп. инструментов всё придёт к вездесущим memo, useMemo, useCallback или настолько большой декомпозиции, что и сам ногу сломишь, и React будет не рад такому количеству нод.
Такой проблемы нет у классовых компонентов потому что там есть конструктор и инициализация. А если хочешь использовать функции, то придется делать "танцы с бубном" чтобы подобный компонент не фризил.
Мой пример (точнее пакет) добавляет возможно использовать аналог конструктора в функциональных компонентах, что иногда очень удобно и позволяет делать некоторые вещи (как перенос данных между рендерами, useRef если без пакета, а с ним просто переменная в "конструкторе") более просто и понятно.
Иной взгляд на React компоненты