I tried React Compiler today, and guess what… real life is a bit more complicated.
Автор вспоминает сновные обещания React Compiler:
- "plug-and-play" - просто устанавливать и всё само работает;
- не нужно думать о React.memo, useMemo и useCallback;
Но что, если проверить на практике?
На простых изолированных примерах Компилятор работал как обещано - автоматически мемоизировал компоненты.
Но когда Compiler был запущен на 3 реальных React-приложениях, он смог исправить только 1-2 из 8-10 случаев лишних перерендеров.
Чтобы React Compiler работал корректно, автору пришлось сделать некоторые оптимизации вручную — извлекать компоненты и использовать мемоизацию.
Вывод: полностью забыть про ручную мемоизацию после использования RC не получится — по-прежнему нужно хорошо понимать эти техники, чтобы регулярно использовать. Потребность в них не исчезла.
https://www.developerway.com/posts/i-tried-react-compiler
Автор вспоминает сновные обещания React Compiler:
- "plug-and-play" - просто устанавливать и всё само работает;
- не нужно думать о React.memo, useMemo и useCallback;
Но что, если проверить на практике?
На простых изолированных примерах Компилятор работал как обещано - автоматически мемоизировал компоненты.
Но когда Compiler был запущен на 3 реальных React-приложениях, он смог исправить только 1-2 из 8-10 случаев лишних перерендеров.
Чтобы React Compiler работал корректно, автору пришлось сделать некоторые оптимизации вручную — извлекать компоненты и использовать мемоизацию.
Вывод: полностью забыть про ручную мемоизацию после использования RC не получится — по-прежнему нужно хорошо понимать эти техники, чтобы регулярно использовать. Потребность в них не исчезла.
https://www.developerway.com/posts/i-tried-react-compiler
This media is not supported in your browser
VIEW IN TELEGRAM
Мне кажется, что менять со скругленного на квадратную кнопку-свитч это как минимум странно.
Что это вообще за компонент такой?
Что это вообще за компонент такой?
Документация patronum переехала на Starlight с Docusaurus.
К сожалению, starlight не супер кастомизируемый, а писать полностью свой documentation builder это довольно серьезный труд.
Чтобы список операторов появился в сайдбаре, хорошо бы дождаться этого Discussion.
Потрогать новую версию:
patronum.effector.dev
К сожалению, starlight не супер кастомизируемый, а писать полностью свой documentation builder это довольно серьезный труд.
Чтобы список операторов появился в сайдбаре, хорошо бы дождаться этого Discussion.
Потрогать новую версию:
patronum.effector.dev
Десятый тейк справедлив и обоснован, но рассматривается с неправильного угла.
В js тоже можно сделать бесконечный цикл вешающий вкладку.
Автор требует от инструмента очень больших ограничений накладываемых на код.
Effector же дает определенную свободу в описании сценариев выполнения. Таким образом развязывая программисту руки в реактивном коде.
Я бы сказал, что effector это реактивная прослойка поверх js. Если хочется жутко ограниченную систему, которая требует сложных систем, вроде DI и IoT-контейнеров, то это не сюда; по крайней мере пока.
В js тоже можно сделать бесконечный цикл вешающий вкладку.
Автор требует от инструмента очень больших ограничений накладываемых на код.
Effector же дает определенную свободу в описании сценариев выполнения. Таким образом развязывая программисту руки в реактивном коде.
Я бы сказал, что effector это реактивная прослойка поверх js. Если хочется жутко ограниченную систему, которая требует сложных систем, вроде DI и IoT-контейнеров, то это не сюда; по крайней мере пока.
ИТОГИ
Здесь мои супер субъективные набросы. Обратите внимание, что я высказываю свою точку зрения и могу ошибаться на счет других людей.
1. Тейки про производительность стоит десять раз проверять.
Автор сделал выводы о производительности и внутреннем устройстве библиотеки на основе поверхностного исследования и пишет статью об этом как эксперт.
Это грустно, но что поделать.
2. Документация сейчас действительно не объясняет ценность инструмента и как им глобально пользоваться.
Это минус, которым сейчас занимается effector core team.
Держим в уме.
3. Тейки про простоту кода основаны на сравнении простых примеров, хотя в самом начале автор пишет, что документация рассматривает тривиальные, далёкие от реальности примеры вроде счётчика.
Почему не показать как надо? Зачем повторять в статье такие же тривиальные примеры?
С разделом выводы я согласен.
Читать статью стоит хладнокровно, критично, объективно и взвешенно.
Это негативный опыт, причиной которого стал в основном недостаток обучающих гайдов и желания разбираться.
Он ценен, во первых критическим взглядом на статьи, даже от гигантов вроде VK.
А во вторых, подсвечивая слабые места и как их можно исправить.
Как помочь?
1) Прийти на effector.dev, почитать всё что есть, предложить изменения через Edit this page.
2) Открыть issues, вычитать то, что вы понимаете, вписать своё мнение, предложить решение, открыть PullRequest.
3) Создать новый issue, которого еще не было, но который важно обсудить.
Спасибо всем, кто вкладывается в создание и улучшения effector.
🧡
Здесь мои супер субъективные набросы. Обратите внимание, что я высказываю свою точку зрения и могу ошибаться на счет других людей.
1. Тейки про производительность стоит десять раз проверять.
Автор сделал выводы о производительности и внутреннем устройстве библиотеки на основе поверхностного исследования и пишет статью об этом как эксперт.
Это грустно, но что поделать.
2. Документация сейчас действительно не объясняет ценность инструмента и как им глобально пользоваться.
Это минус, которым сейчас занимается effector core team.
Держим в уме.
3. Тейки про простоту кода основаны на сравнении простых примеров, хотя в самом начале автор пишет, что документация рассматривает тривиальные, далёкие от реальности примеры вроде счётчика.
Почему не показать как надо? Зачем повторять в статье такие же тривиальные примеры?
С разделом выводы я согласен.
Читать статью стоит хладнокровно, критично, объективно и взвешенно.
Это негативный опыт, причиной которого стал в основном недостаток обучающих гайдов и желания разбираться.
Он ценен, во первых критическим взглядом на статьи, даже от гигантов вроде VK.
А во вторых, подсвечивая слабые места и как их можно исправить.
Как помочь?
1) Прийти на effector.dev, почитать всё что есть, предложить изменения через Edit this page.
2) Открыть issues, вычитать то, что вы понимаете, вписать своё мнение, предложить решение, открыть PullRequest.
3) Создать новый issue, которого еще не было, но который важно обсудить.
Спасибо всем, кто вкладывается в создание и улучшения effector.
🧡