Почитал отчёт о нём за прошлый год. Рад что они занимаются этой проблемой. И да, это большее чем я написал. Правда ещё не ясно можно ли его будет использовать на разных версиях react
Прошло почти два года и пока не стандарт. Надеюсь они делают что-то большее чем просто автодобавление даже аналогов useMemo и useCallback. Одно дело когда функция статична и никогда не вызовет ререндер, даже если в ней используется состояние. А другое когда функция на каждое изменение будет всё равно создаваться заново (использование useCallback с зависимостью в виде состояния).
Как без HOC добавить классу общий функционал (применяемый в нескольких компонентах), использующий состояние или метод жизненного цикла? Ещё и полностью типизированный ;)
Гибкость в более простом создании переиспользуемой логики. Для классов есть только путь HOC или заморочкой с наследованием/передачей this, что в больших объёмах понижает производительность, да и читается хуже чем обычный хук в функциональщине.
Лично мне нравится и классовый и функциональный подход, но во втором вечно была проблема с ререндерами, которую библиотека пытается минимизировать.
@preact/signals это про управление состоянием. Тут же единственная фича - инициализатор (или же "конструктор", как угодно), плюс функции, позволяющие в нём использовать аналогичный react-хукам функционал. Уменьшение ререндеров следует из этой фичи. Все колбеки и переменные из инициализатора не вызывают ререндер, так как ссылка на них не меняется в течение всего жизненного цикла.
В обычном функциональном компоненте ссылка на любую функцию будет новая каждый рендер. Также все переменные будут созданы заново. При передаче в компонент они вызовут его ререндер (даже компонента в memo, исключение - строки и числа, они сравниваются по значению). Именно по этой причине нет смысла оборачивать в memo компонент, принимающий children,так как это массив и он имеет разную ссылку при каждом рендере.
Это довольно назойливая проблема реакта, которая в один момент может заставить фризить всё приложение и придётся использовать useMemo / useCallback / useRef.
Вся библиотека react-afc это лишь обёртка над обычным react. Даже сама функция afc лишь создаёт функциональный компонент с некоторым функционалом, который в качестве представления возвращает результат render-функции.
memo работает с пропсами компонента, то есть позволяет не ререндерить сам компонент если входные данные идентичны. afc же добавляет инициализатор компонента, позволяя при изменении состояния не ререндерить дочерние компоненты который в этом не нуждаются. Также есть afcMemo, который добавляет и то и другое (afc оборачивается в memo)
Библиотечные компоненты как правило оптимизированы и сами по себе не вызывают проблем (если их правильно использовать). Есть совместимое API у библиотеки, можно писать хуки для обычных и для afc компонентов одновременно, при этом само написание остаётся идентичным в 90% случаев. С точки зрения использования компонента разницы нет, те же пропсы, callback'и и всё остальное. Вся работа идёт внутри, а снаружи то же самое API компонента (afc возвращает React.FC).
Если сами разработчики react предоставили инструменты для того чтобы бороться с ререндерами, то почему бы не упростить их использование? Если взять UI либу (Antd к примеру, а уж теб более MIU), то ой как встанет вопрос о сокращении лишних отрисовок, ибо даже 20-30 дополнительных отрисовок сложных компонентов будут фризить всё приложение.
Можно. Эта библиотека не заменяет (и даже не пытается делать этого) такие инструменты как MobX. Лишь выступает как небольшое добавление функционала к оригинальному react.
Если в переиспользуемом компоненте есть сложная логика, то решая проблему оптимизации без доп. инструментов всё придёт к вездесущим memo, useMemo, useCallback или настолько большой декомпозиции, что и сам ногу сломишь, и React будет не рад такому количеству нод.
Такой проблемы нет у классовых компонентов потому что там есть конструктор и инициализация. А если хочешь использовать функции, то придется делать "танцы с бубном" чтобы подобный компонент не фризил.
Мой пример (точнее пакет) добавляет возможно использовать аналог конструктора в функциональных компонентах, что иногда очень удобно и позволяет делать некоторые вещи (как перенос данных между рендерами, useRef если без пакета, а с ним просто переменная в "конструкторе") более просто и понятно.
Мне самому также не нравится что разработчики реакта смотрят в сторону хуков. Не будь у них проблем - не было бы этой статьи. Использовать классы или функции это выбор каждого, поэтому хотелось бы видеть их одинаковую поддержку и развитие. Но что есть то есть..
Почитал отчёт о нём за прошлый год. Рад что они занимаются этой проблемой. И да, это большее чем я написал.
Правда ещё не ясно можно ли его будет использовать на разных версиях react
Прошло почти два года и пока не стандарт.
Надеюсь они делают что-то большее чем просто автодобавление даже аналогов
useMemoиuseCallback. Одно дело когда функция статична и никогда не вызовет ререндер, даже если в ней используется состояние. А другое когда функция на каждое изменение будет всё равно создаваться заново (использованиеuseCallbackс зависимостью в виде состояния).Как без HOC добавить классу общий функционал (применяемый в нескольких компонентах), использующий состояние или метод жизненного цикла?
Ещё и полностью типизированный ;)
Гибкость в более простом создании переиспользуемой логики.
Для классов есть только путь HOC или заморочкой с наследованием/передачей this, что в больших объёмах понижает производительность, да и читается хуже чем обычный хук в функциональщине.
Лично мне нравится и классовый и функциональный подход, но во втором вечно была проблема с ререндерами, которую библиотека пытается минимизировать.
@preact/signalsэто про управление состоянием.Тут же единственная фича - инициализатор (или же "конструктор", как угодно), плюс функции, позволяющие в нём использовать аналогичный react-хукам функционал.
Уменьшение ререндеров следует из этой фичи. Все колбеки и переменные из инициализатора не вызывают ререндер, так как ссылка на них не меняется в течение всего жизненного цикла.
В обычном функциональном компоненте ссылка на любую функцию будет новая каждый рендер. Также все переменные будут созданы заново. При передаче в компонент они вызовут его ререндер (даже компонента в
memo, исключение - строки и числа, они сравниваются по значению).Именно по этой причине нет смысла оборачивать в
memoкомпонент, принимающийchildren,так как это массив и он имеет разную ссылку при каждом рендере.Это довольно назойливая проблема реакта, которая в один момент может заставить фризить всё приложение и придётся использовать
useMemo / useCallback / useRef.Вся библиотека react-afc это лишь обёртка над обычным react.
Даже сама функция
afcлишь создаёт функциональный компонент с некоторым функционалом, который в качестве представления возвращает результат render-функции.То есть да, никакая интеграция не требуется.
Хорошее замечание. Обязательно подумаю над переименованием
useStateвuseSignalmemoработает с пропсами компонента, то есть позволяет не ререндерить сам компонент если входные данные идентичны.afcже добавляет инициализатор компонента, позволяя при изменении состояния не ререндерить дочерние компоненты который в этом не нуждаются.Также есть
afcMemo, который добавляет и то и другое (afcоборачивается вmemo)Библиотечные компоненты как правило оптимизированы и сами по себе не вызывают проблем (если их правильно использовать).
Есть совместимое API у библиотеки, можно писать хуки для обычных и для afc компонентов одновременно, при этом само написание остаётся идентичным в 90% случаев.
С точки зрения использования компонента разницы нет, те же пропсы, callback'и и всё остальное. Вся работа идёт внутри, а снаружи то же самое API компонента (afc возвращает React.FC).
Да, в этом и смысл. Сохранить в функциональном компоненте его гибкость и при этом добавить немного возможностей классов.
Если сами разработчики react предоставили инструменты для того чтобы бороться с ререндерами, то почему бы не упростить их использование?
Если взять UI либу (Antd к примеру, а уж теб более MIU), то ой как встанет вопрос о сокращении лишних отрисовок, ибо даже 20-30 дополнительных отрисовок сложных компонентов будут фризить всё приложение.
Можно. Эта библиотека не заменяет (и даже не пытается делать этого) такие инструменты как MobX. Лишь выступает как небольшое добавление функционала к оригинальному react.
Если в переиспользуемом компоненте есть сложная логика, то решая проблему оптимизации без доп. инструментов всё придёт к вездесущим memo, useMemo, useCallback или настолько большой декомпозиции, что и сам ногу сломишь, и React будет не рад такому количеству нод.
Такой проблемы нет у классовых компонентов потому что там есть конструктор и инициализация. А если хочешь использовать функции, то придется делать "танцы с бубном" чтобы подобный компонент не фризил.
Мой пример (точнее пакет) добавляет возможно использовать аналог конструктора в функциональных компонентах, что иногда очень удобно и позволяет делать некоторые вещи (как перенос данных между рендерами, useRef если без пакета, а с ним просто переменная в "конструкторе") более просто и понятно.
Объект
propsавтоматически обновляется каждый рендер (не передаётся новый объект, а изменяются его свойства)Мне самому также не нравится что разработчики реакта смотрят в сторону хуков. Не будь у них проблем - не было бы этой статьи.
Использовать классы или функции это выбор каждого, поэтому хотелось бы видеть их одинаковую поддержку и развитие. Но что есть то есть..
Уже исправляю видимость состояния в ReactDevtools и показ названия компонента в древе