я в курсе. Это пример абстрактный

Вот видишь, бизнес идёт на то, чтобы переписать всё с нуля.)) А ради улучшения прозиводительности не меняет слой представления, что странно на мой взгляд

Жень, покидай примеры кода пожалуйста. Очень буду благодарен.

Не холивара ради, а ради расширения кругозора. Что значит удобный код (в твоём понимании)?

Так может и бизнес-логика говно? Как раз менять слой представления это решение более странное.

Я бы покидал, если есть конкретная задача

тогда зачем каждый новый фреймворк трубит о том, что он более производительный, чем все предыдущие?

он как вообще на бизнес логику завязан?

С нуля писать быстрее и сразу эффективнее. Переписывать думаю профиты меньше

Насколько я понимаю, у Реакта изначально не было цели убирать логику из шаблонов, наоборот он даёт возможность иметь логику в шаблонах. За это его ругали поначалу, но по-моему это один из его главных плюсов.

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

C нуля конечно же эффективнее, но жизнь такая штука… что приходится и в говне покопаться.

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

я повторюсь, что это мой абстрактный пример.

Когда в редаксе хранятся селекторы и экшн крейтеры, написанные так из-за того, что редакс это продиктовал
А не потому что надо держать в голове, что когда-нибудь придёт новый сотрудник и захочет поменять фреймворк и надо попробовать это предугадать

Например тебе не всё надо выносить в редакс, когда ты пишешь приложение, а какую-то логику можешь не класть в стор и реализовать её средствами компонента и это будет удобно

Ок. Я привёл идиотский пример про (поменять слой представления). Согласен. Что касается логики в компонентах, то я руководствуюсь следующими правилами. Если логика имеет смысл только в рамках ui компонента (слайдеры, аккортионы и тд) то пишу это в state компонента. Если это бизнес логика, тогда уношу в стейт менеджер.

селекторы, saga/ thunk и тд я вообще не использую

всё это есть из коробки в Effector. Так же как и типизация для flow / ts

вернее селекторы там просто не нужны, а saga / thunk замененты effect

@nglazov Ты не поверишь, но мы всей командой не испытваем не малейшего неудобства от того, что у effector нет devtools. Он спроектирован так, что ты всегда можешь спосмотреть что у тебя происходит в store, event, effect