Для тех кто может хоть сколько нибудь адекватный совет дать, прошу посмотреть Народ, посмотрите пожалуйста этот код https://codesandbox.io/s/rdg-cell-editing-ozmv8?fontsize=14 Есть компонент Example. Его надо переписать в функциональном стиле. Я сделал Example2 и использую хук состояния. Однако при обновлении таблицы (нужно кликнуть на ячейку и потянуть за угол вниз), когда я вызываю хук setRows, перерендеринга не происходит. Что я делаю не так?

[...rowsState]

Извиняюсь я был неправ, посмотрел реализацию useState, там используется Object.is для сравнения предыдущего и нового значения, я был уверен что вызов setState безусловно вызывает перерендер

Т.е. правильно я понимаю что сколько бы я не вызывал setState хук с объектом по одной и той же ссылке - никогда не произойдет ререндер? Только новый объект надо создавать?

Не понимаю зачем раздавать советы сидя в телефоне и не имея возможности код посмотрить, и не читая вобще вопроса.

Cпасибо за объяснение.

Какая логика должна быть в кастомных хуках? Вообще вся что только можно, а визуалка отдельно? Или есть какое-то общепринятое определение?

Во во. Поэтому я тихо сижу, молчу и жду ответа с телефона

Ну в итоге то разобрались...

ну так логика в хуках это и есть логика в компонентах это то и плохо а без этого наверное и аполло не нужон 🧐

А какие причины выносить бизнес логику от реакта подальше?

некоторым нравится mvc

А как mvc с реактом подружить?

А как mvc с реактом подружить?

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

А какие причины выносить бизнес логику от реакта подальше?

Я тут стал чаще задавится этим вопросом. Наверное самое первое, мне нравится модель mvc. Ее лучше поддерживать и переиспользовать. И опыт такой имеется. Ещё можно заменить реакт если потребуется. Но это теория.

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

Нужно наверное уточнить на каких обьемах аппы это оправдано

Ну нужна новая фича. Она требует пару моделей из какой-то верхней уровня логики. Ещё сдо десяти сервисов. И лучше обернуть вью часть в стейт машину. Я не представляю как предложить максимально эластичный функционал инструментов, что бы это быстро собрать без mvc. А такое особенно часто встречается в стартапах. Делали одно, потом за вечер все поменялось и нужно переписывать кучу логики. И рыться в реакте? Посмотри в сторону inversifyJS. Как модно организовывать (микро) сервисы и переиспольщованностл компонентов бизнес логики. Крч. Когда всего не утаить в реакте. Когда это становится слишком сложно для человеческого мозга. Это нужно разделять на простые модели. А зачем для их описания использовать реакт? Лучше нативный ес 6

Спасибо за развернутый ответ. Дополнения остальных 2200 приветствуются

Спасибо за развернутый ответ. Дополнения остальных 2200 приветствуются

Я считаю мы в команде должны основываться на определённых методологиях разработки. Используя уже описанные паттерны и алгоритмы. Это увеличивает объём кодовой базы. Но при правильных методологиях (прим. SOLID). Любой участник проекта просто не сможет долго и методично говнокодить. Я пришёл к этой мысли. Тк когда стартап проект начинает приобретать форму почти каждое добавление нового функционала влечёт изменение текущего. Разбивка его на более мелкие кусочки. Которые нужно подвергать тестированию. И уже из них создать композиции. Таким образом что то будет удаляться, что то добавляться. Я не уверен, что такое возможно сделать только на реакте. Все. Кончил. А не... на пример ты работаешь с каким то динамическим списком. Ок. Ты можешь проконтролировать динамический рендер дерева одного модуля в приложении. А если эти данные должны асинхронно меняться и в соседних компонентах? А если и на всех вкладках? Все превращать в помойку через контекст? Вот эта бизнес логика по тому как сущности должны меняться, общаться с беком. Лучше убрать из вью части приложения. А как это сделать лучше я хз. <3 имхо

Что такое динамический рендер дерева?

Что такое динамический рендер дерева?

Что то случайное из головы. Пускай будет огромный список данных. Который мы может изменять через бек. А некоторые из данных (из списка) ещё отображаем в соседних компонентах. Никак не связанных с этим. Не давно смотрел как реакт делает перерендер внутренне компонентов. Особенно если это массив данных. А в них другие данные. И все это крутится. Вертится. Сортируется и тп

Блин. Не могу найти супер пример. Был в слаке на предыдущей работе. А меня выкинула безопасность ((

Реакт делает все правильно, если уперлись в производительность, то есть способы решить проблемы

да, хотел показать пример с этим. Пусть реакт остается на рендер. Но всю логику с работой этих данных вынести из него. Пускай думает только над рендером.

React Window не то?

Реакт это не только view, это и controller и model для данных (в какой-то степени), мой поинт в том что MVC не ложится совсем на подход реакта

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

ложится если его брать только для V

Я про динамический рендеринг

я точно не правильно выразился. =(

Но user interaction это же не view, это controller ?

то как будет регаировать вью отнюдь не обязательно в реакте держать

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

Костыли вокруг жизненного цикла? Не сталкивался

видимо речь идет о всякого рода мемоизациях и завязывании на ЖЦ компонентов бизнес логики

Скажем так, а есть пример опенсорсного приложения уровня выше хеллоу ворлда, где модно в действии такой подход увидеть?

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

Что то не могу найти, ужс какой то. Точно есть, близкое можно это посмотреть. Хорошие практики и советы: https://github.com/labs42io/clean-code-typescript

Тут есть конкретная зависимость от обьема аппы. Чем меньше тем подход более оверхед

Спасибо, почитаю с утра на свежую голову. Но хочется реальный проект всё-таки увидеть

пока мне нечего показать...

только увидел https://ota-solid.now.sh/ выглядит очень круто. Прочитайте (сам буду читать)

ООП ох :) но спасибо в любом случае, прочту

я ООП мог пересказать, но только через солид методологию стал понимать как на самом деле можно опираться на ООП и не сломать себе тельце

Нужно наверное уточнить на каких обьемах аппы это оправдано

Просто мы тут о реакте конкретно стараемся говорить, а не о GUI в общем, так вот реакт не очень то ООПная штука, и как вписать его в ОО систему не понятно

Да я все стесняюсь добавить. Просто мне оч нравится Bem-react. Очень свеженький продукт. И в экосистеме реакта

всем привет! кто-то использует кубик-безье трансформацию?И если да - то где?