Wat? useCallback возвращает стабильную ссылку на лямбду, меняя только в случае, если меняются зависимости. Зачем такой бред писать. Если же не верите, посмотрите исходники для начала.
Вот вам ссылочка, если лень искать. Если же хотите всю цепочку до useCallback, уж поищите сами.
По сути — просто визуализация текущего состояния, плюс обработка действий пользователя. Не надо пилить логику на Реакте, тогда не будет трудностей.
Даже сделать страницу, которая показывает некий документ с сервера. Так или иначе в в стартовом useEffect надо инициировать запрос, потом надо собственно дождаться ответа, проверить не размаунтился ли уже компонент, обновить состояние. Это уже асинхронщина.
Идём дальше, у нас master-slave представление, где детали подтягиваются с сервера непосредственно при выборе элемента в master представлении.
Идём дальше, у нас есть чарт, который должен регулярно обновлять данные, система мониторинга.
И всё это должен инициировать некий компонент, обрабатывать, оно само по себе жить не будет.
А идём ещё дальше, необходимо обрабатывать много данных, заводим WebWorker, в нём обработка, UI не тормозит, но ожидать результат требуется, это опять асинхронщина.
Какие минусы? Перечислите пожалуйста, и желательно реальные минусы
Большая проблема MobX, это оборачивание в Proxy для реализации observable, собственно это ещё грозит потерями ссылок, в итоге объекты уже не сравнить по ссылкам после MobX. При этом оборачивание в глубину. Я конечно понимаю, что можно вырубить, но тогда теряется весь смысл MobX. Производительность от этого местами страдает ничем не меньше чем с Redux. Если уже и смотреть, то лучше в сторону MST (MobX State Tree), он не оборачивает в Proxy, но требует строгого описание типов, что на деле другая, совсем не маленькая проблема.
Почему в нашем случае MobX не подойдёт, у нас хранятся таблицы, временами на сотни тысяч строк, если это ещё заворачивать в Proxy, аааа, будет кошмар, оно и без этого сильно тормозит при обработке таблиц. В нашем случае иммутабельность даже является спасением.
Опять некая статья, где тупо забивается на useCallback, что приведёт к постоянному перерендеру детей, даже когда этого не требуется. А данная проблема копаться как снежный ком. Хотя что говорить, когда даже в официальной документации данный момент игнорируется.
Ну давай, расскажи, как же готовить Redux для работы с древовидными данными? Когда конечное приложение - дерево. И уж MobX не надо тут рекламировать, я понимаю, он вам нравится, но минусов у него достаточно. Вообще в нашей архитектуре куда лучше подойдёт RxJS, хотя смотрим сейчас на Effector и потихоньку рефакторим приложение, для безболезненного перехода, точнее менее безболезненного. Ибо бизнес-логику надо будет перелопачивать, знатно перелопачивать.
А вот DI должен быть либо везде, либо нигде, ведь идея в том, что создаётся только базовый объект приложения, далее всё разруливает именно IoC контейнер. В ином случае просто теряется весь смысл. О функции "resolve" надо забыть, вызываться должна ровно 1 раз. В случае с React этого добиться невозможно. Собственно выйдет знатный антипаттерн.
Ещё минус React, не скажу как внутри, но снаружи он синхронен, в этом его колосальная проблема. Так или иначе появляется слой перехода асинхронного и синхронного. Кругом нужны костыли для поддержки полноценной асинхроннсти. После к примеру WPF и ASP.NET MVC на это очень больно смотреть.
Так чем функциональные компоненты спасают от SRP? Голые может быть и спасли бы, но в этом случае вы не способны реализовать полноценный компонент, либо это затребует слишком большого оверхеда в виде большущей куче мелких компонентов, которые вы более нигде и никогда использовать всё равно не будете.
В React же дали хуки, что привели на деле только к куда более худшей ситуации. Код стал менее тестируемым, с использованием IoC от Angular вы тестируете сервис, без каких-либо зависимостей и вы действительно знаете, его зависимости и спокойно заменяете мок-зависимостями (фейками, пустышками и т.д.), в React вы не знаете зависимости, в принципе, мокнуть по правильному код реакта просто невозможно, вам так или иначе придётся лезть в приватный код, чтобы хоть как-то протестировать компонент.
А ведь какой-нибудь простенький компонент может к примеру запрашивать по http данные, это в React будет реализовано в useEffect на старте или в useCallback по клику мышкой. Как вы будете подменять данный код в тестах? У вас просто нет легальной возможности это сделать.
P.S. Мы сейчас работаем над визуальной IDE на React, с кучей готовых компонентов, изначально я не хотел выбирать React + Redux для этой задачи, но сверху сказали. Теперь проект превратился в какой-то адский ад. Тестировать невозможно. Вынести адекватно бизнес-логику совершенно отдельно от React и Redux просто невозможно, а её ну очень много. React не поддерживает IoC и мы в общем не можем вынести общие сервисы для работы в рамках компонентов и редьюсеров, всю логику нельзя унести в редьюсеры, это потребует очень большого оверхеда. Ах да, структура приложения древовидна, редакс в принципе не предназначен для этого, любой чих в итоге — полная перерисовка всего. Потребовалось делать подсистему кэширования. В итоге проект превратился в сборище костылей лишь потому, что выбран неподходящий ниструмент.
И надеятся, что заработает, да ещё при этом активировать строго по окончанию предыдущего? И по факту это обычный Gold, что можно и так купить по подобным ценам в любом магазине?
Minecraft сервер на Raspberry? Вы видно шутите? Сколько выдержит, половину игрока осилит? Если без модов. Увы, проц надо очень мощный ему, особенно если с модами, особенно если какой-нить тяжёлый модпак.
Дело не в том, что бы что-то делать. Обычно PET проекты делаются не для тяп-ляп, а для реального морального удовольствия. И изучение нового языка программирования даёт знатное удовольствие. Я вот занимаюсь электроникой ну где-то месяца 4, до этого знал название электронных компонентов, но тонкостей работы не знал. К примеру считал, что транзистор = реле, как же я заблуждался. Разобрался с работой базовых компонентов, типовые схемы подключения, как работают усилители и т.д. И уж если я уж знаю кучу ЯП, в том числе и C/C++, мне нет смысла изучать язык, но я углубился в изучение компонентной базы. В качестве PET проекта в итоге уже закончил переключатель аудиовыходов (1 вход, несколько выходов), работает от пульта ДУ телевизора, при этом из готовых модулей только Arduino Nano, да, пока не готов к разводке, хотя планирую на следующем проекте уже частично разводить сам под микроконтроллеры.
Ну да, ремонтопригодность нулевая, цена при этом в таких масштабах уже конская. При этом требования бывают разные и обвес таких макеток не всегда хорош. Взять ардуину, ох и как же плохо с энергосбережением у них, нереально ужасно. При этом распаяв отдельно чип, можно получить довольно хороший уровень энергосбережения. Подобные платки для штучных прототипов вкатят, но не для массового производства, какой к примеру завод возьмётся распаивать это на плату?
Урезанный спектр никого не напрягает? Не думаю, что в лампочках стоят светодиоды с линейными характеристиками по спектру. Проведите хотя бы тесты для подобных ламп. Вы же вроде тестированием и занимаетесь, или после апгрейда характеристики становятся таковыми, что глаза потом придется выбросить? И лучше это не показывать?
Да, кривость решения сложно отрицать. Просто учитывая, сколько самопальных клавишных блока есть и сколько там клавиш, можно сказать одно, в изучении электроники он добрался до уровня соединения готовых модулей проводками и всё.
Я говорил про использование NodeJS. Есть куда более подходящие инструменты для этого. В данном случае можно было потратить несколько дополнительных часов от силы, чтобы сделать это же самое на .NET к примеру.
Оо, вот это жесть. Про микроконтроллер молчу, но что за программная жесть? Неужели кроме NodeJS больше никак не сделать такой мелкую прикладуху для PC? Реально для этого надо тратить море ресурсов, ставить NodeJS для работы и т.д.? Такое реализуется даже на C/C++ элементарно.
MVVM не главная боль. Перегруженные привязки, можно уж и попроще было, Avalinia ведь смогла. Опять же без некоторых доп зависимостей всё же пользоваться неудобно, очень. К примеру стандартными средствами крайне больно добавлять свою функциональность к сторонним компонентам.
Что-то мне подсказывает, что такие проекты уже есть. Да и не вижу смысла расписывать мысли. Сначала надо что-то сделать сам вот недавно занялся подобным и понял, что часто микроконтроллеры — стрельба из пушки по воробьям. В итоге, молчу, читаю книги. При этом так, по мелочи сделал уже пару девайсов.
В этом смысле memo, ну да, тут согласен. Что-то не совсем правильно понял вышенаписанное.
Wat? useCallback возвращает стабильную ссылку на лямбду, меняя только в случае, если меняются зависимости. Зачем такой бред писать. Если же не верите, посмотрите исходники для начала.
Вот вам ссылочка, если лень искать. Если же хотите всю цепочку до useCallback, уж поищите сами.
https://github.com/facebook/react/blob/568dc3532e25b30eee5072de08503b1bbc4f065d/packages/react-reconciler/src/ReactFiberHooks.new.js#L1623
А бред пожалуйста не пишите более, а то я тут чуть под стол не упал.
Даже сделать страницу, которая показывает некий документ с сервера. Так или иначе в в стартовом useEffect надо инициировать запрос, потом надо собственно дождаться ответа, проверить не размаунтился ли уже компонент, обновить состояние. Это уже асинхронщина.
Идём дальше, у нас master-slave представление, где детали подтягиваются с сервера непосредственно при выборе элемента в master представлении.
Идём дальше, у нас есть чарт, который должен регулярно обновлять данные, система мониторинга.
И всё это должен инициировать некий компонент, обрабатывать, оно само по себе жить не будет.
А идём ещё дальше, необходимо обрабатывать много данных, заводим WebWorker, в нём обработка, UI не тормозит, но ожидать результат требуется, это опять асинхронщина.
Большая проблема MobX, это оборачивание в Proxy для реализации observable, собственно это ещё грозит потерями ссылок, в итоге объекты уже не сравнить по ссылкам после MobX. При этом оборачивание в глубину. Я конечно понимаю, что можно вырубить, но тогда теряется весь смысл MobX. Производительность от этого местами страдает ничем не меньше чем с Redux. Если уже и смотреть, то лучше в сторону MST (MobX State Tree), он не оборачивает в Proxy, но требует строгого описание типов, что на деле другая, совсем не маленькая проблема.
Почему в нашем случае MobX не подойдёт, у нас хранятся таблицы, временами на сотни тысяч строк, если это ещё заворачивать в Proxy, аааа, будет кошмар, оно и без этого сильно тормозит при обработке таблиц. В нашем случае иммутабельность даже является спасением.
Опять некая статья, где тупо забивается на useCallback, что приведёт к постоянному перерендеру детей, даже когда этого не требуется. А данная проблема копаться как снежный ком. Хотя что говорить, когда даже в официальной документации данный момент игнорируется.
Ну давай, расскажи, как же готовить Redux для работы с древовидными данными? Когда конечное приложение - дерево. И уж MobX не надо тут рекламировать, я понимаю, он вам нравится, но минусов у него достаточно. Вообще в нашей архитектуре куда лучше подойдёт RxJS, хотя смотрим сейчас на Effector и потихоньку рефакторим приложение, для безболезненного перехода, точнее менее безболезненного. Ибо бизнес-логику надо будет перелопачивать, знатно перелопачивать.
А вот DI должен быть либо везде, либо нигде, ведь идея в том, что создаётся только базовый объект приложения, далее всё разруливает именно IoC контейнер. В ином случае просто теряется весь смысл. О функции "resolve" надо забыть, вызываться должна ровно 1 раз. В случае с React этого добиться невозможно. Собственно выйдет знатный антипаттерн.
Ещё минус React, не скажу как внутри, но снаружи он синхронен, в этом его колосальная проблема. Так или иначе появляется слой перехода асинхронного и синхронного. Кругом нужны костыли для поддержки полноценной асинхроннсти. После к примеру WPF и ASP.NET MVC на это очень больно смотреть.
В React же дали хуки, что привели на деле только к куда более худшей ситуации. Код стал менее тестируемым, с использованием IoC от Angular вы тестируете сервис, без каких-либо зависимостей и вы действительно знаете, его зависимости и спокойно заменяете мок-зависимостями (фейками, пустышками и т.д.), в React вы не знаете зависимости, в принципе, мокнуть по правильному код реакта просто невозможно, вам так или иначе придётся лезть в приватный код, чтобы хоть как-то протестировать компонент.
А ведь какой-нибудь простенький компонент может к примеру запрашивать по http данные, это в React будет реализовано в useEffect на старте или в useCallback по клику мышкой. Как вы будете подменять данный код в тестах? У вас просто нет легальной возможности это сделать.
P.S. Мы сейчас работаем над визуальной IDE на React, с кучей готовых компонентов, изначально я не хотел выбирать React + Redux для этой задачи, но сверху сказали. Теперь проект превратился в какой-то адский ад. Тестировать невозможно. Вынести адекватно бизнес-логику совершенно отдельно от React и Redux просто невозможно, а её ну очень много. React не поддерживает IoC и мы в общем не можем вынести общие сервисы для работы в рамках компонентов и редьюсеров, всю логику нельзя унести в редьюсеры, это потребует очень большого оверхеда. Ах да, структура приложения древовидна, редакс в принципе не предназначен для этого, любой чих в итоге — полная перерисовка всего. Потребовалось делать подсистему кэширования. В итоге проект превратился в сборище костылей лишь потому, что выбран неподходящий ниструмент.
У медведя не ультрабаза, а порнография, после эникубика, ей нереально пользоваться. К ней ничего не липнет.
Что-то мне подсказывает, что такие проекты уже есть. Да и не вижу смысла расписывать мысли. Сначала надо что-то сделать сам вот недавно занялся подобным и понял, что часто микроконтроллеры — стрельба из пушки по воробьям. В итоге, молчу, читаю книги. При этом так, по мелочи сделал уже пару девайсов.