Comments 7
Может в тегах, хабах, заголовке или превью указать, что речь идет о React?
Или для вас весь фронтенд - это только React?
Effector и farfetched не завязаны на реакт. Ту же логику точно также можно рендерить хоть на Солид, хоть на Вью.
Нужно в статью добавить про тесты, станет понятнее почему это ещё более выгодно, чем просто перерендеры.
Скорее в статьях о Vue должно быть упоминание, что они о Vue. С React - нет.
Эффектор не привязан к реакту
Чем плох повторный рендеринг UsersTable? Повторный рендеринг - это не всегда же работа с DOM. Если Fiber дерево компонента получается такое же как и текущее, то там ничего не будет происходить с DOM вообще. К тому же фаза рендеринга в React асинхронная и это не должно как либо отразиться на производительности веб приложения.
Если у вас логика рендеринга без каких либо сайд эффектов, как и рекомендует React команда, то ни на что не должно повлиять.
Так же React пишут, что memo это чисто оптимизация производительности и нужно на неё только опираться, если вы видите реальные тормоза. В том числе потому что использование memo так же не бесплатно.
https://react.dev/reference/react/memo
You should only rely on
memoas a performance optimization. If your code doesn’t work without it, find the underlying problem and fix it first. Then you may addmemoto improve performance.Optimizing with
memois only valuable when your component re-renders often with the same exact props, and its re-rendering logic is expensive. If there is no perceptible lag when your component re-renders,memois unnecessary.
Так же они всё же когда-нибудь обещают выпустить React Forget, где это будет делаться автоматически.
Спасибо за комментарий! Все так, ререндеры в реакт приложениях зачастую не так страшны, это доказано уже очень много раз). В статье, в первую очередь, хотелось рассказать и показать, что происходит, когда вся логика приложения во вью слое. В частности с реактом, когда вся логика находится в компонентах/хуках, компоненты будут ререндериться достаточно часто и это не проблема, но тело компонента будет вызываться на каждый ререндер родителя, что приходится учитывать. Если вынести логику в статическое хранилище, то она перестанет быть настолько связана с жизненным циклом компонентов, что позволит сосредоточится на реализации бизнес-задач, а не на том, как тот или иной фрейморк или библиотека рендерит компоненты.
Если вы делаете что-то такое дикое в теле компонента, что при повторном вызове тела происходят тормоза, то в любом случае надо по разбираться, что там тормозит и использовать useMemo для тормозных вычислений.
Я опять повторюсь, что если ваша логика рендеринга чиста от сайд эффектов и все тормозные участки замемоизированы, тогда нет никакого преимущества от выноса логики в статическое хранилище, так как вы разницу визуально не заметите.
К тому же react разработчики сами пишут, что рендеринг компонента может запускаться и без вашего участия, поэтому стараться уменьшить кол-во перерендеров через такие стейт менеджеры лишено смысла.
React Compiler выпустят в OpenSource и тогда все эти стейт менеджеры у которых единственная глобальная цель оптимизировать рендеринг потеряют актуальность и вам всем потом захочется с таким же энтузиазмом переписывать всё на React state + reducer + context. Кстати в PR-ах в React репу можно найти видео, где разработчик добавил функцию отображения авто-мемоизированных компонентов и уже тестирует на каком-то коде.
Я считаю что чем меньше хлама затащим в проект, тем меньше потом работы будет чтобы выпиливать все это.
И кстати чем плох Redux в рамках RTK Query? Сейчас вместо Redux же предлагается использовать RTK и он вполне уже не так многословен, как оригинальный Redux. В состав входит Immer, можно мутировать стейт, если прям не нравится деструктуризация. useSelector вызывает рендеринг только если стейт, который он возвращает, поменялся. По идее так же точечно как и Effector, MobX будет обновлять компоненты.
Frontend Talks: СТМ нужны! Логика в хуках — плохо?