Согласен с автором, ощутил на себе как тесты экономят время и ресурсы. Я бы еще добавил, что существует тип проектов, как библиотеки, которые в принципе разрабатываются только через написание тестов.
Причем тут сервер? Раговор про фронтовое приложение,в его архитектуре так же есть бизнеслогика, она специффична именно клиенту, но она есть и она не должна быть в слое реакта.
Накидал пример кода как подружить реакт со сторонней либой, Всю реактивность можно запишнуть в DI контейнер и там сохранить бизнеслогику. вызывать апи клиенты, проводить валидации и тп. а из контейнера выставлять именно реактивные пропсы, таким образом на реакт слой прилетают только пропсы и колбеки. Все делается элементарно и не нужно ничего выдумывать. Вместо di контейнера вы можете использовать mvvm, тогда этот хук будет для него binder'ом, а модель может быть рукописным классом
Всегде интересовал вопрос - что вы там такое делаете все, что вам так дико нехватает перформанса?? у вас там что пользователи заполняют формы быстрее чем реакт инпуты рендерит? вы где то на глаз замечаете эти сотые секунды задержки между вводом и ререндером?
и возможности полноценно интегрировать сторонние системы реактивности
Никто вам не мешает использовать для бизнеслогики стороннюю реактивность, от самописной до сигналов. если вы хотите заменить потроха реакта на [любая реактивная библиотека], то возникает вопрос - зачем? И предположу, что любой ваш агрумент будет сводится к тому что вы хотите замешать кучу лишний логики в слой отображения. Которой там быть не должно.
Хуки нужно воспринимать как промежуточное решение, я бы сказал - тестирование концепции, насколько я помню, скоро все сведется к одному хуку use. Если юзать compiler то против вообще можно будет забыть. Северные компоненты сильно упрощают жизнь, особенно если приложение работает на сервере. Так что формально там лишнего нет. Всё необходимое для рендера.
Почему это должно быть сложно? ангуляр живет с этим и проблем не наблюдается.
но в остальных экосистемах выдаются за инновацию
С каких пор использование инструмента по назначению это инновация? реакт это библиотека для рендера. Всегда было непонятно почему все считают его серебренной пулей и жалуются что в него не пичкают ненужным ему хламом.
Большинство людей которые пишут на реакте не понимают что это именно библиотека для отображения UI. Из за того что у них нет технического бекграунда(в большинстве своем это именно так и есть, реакт выбирают вкатуны из за низкого порога входа). Если вы хотите реализовать MV* паттерн, то нужно понять что реакт это именно V, т.е. в компоненты должны прилетать уже готовые данные. И многие не понимают как все собрать в кучу и делают все что предлагает npm. следовательно проект превращается в кладбище пакетов и жирнущую реализацию flux архитектуры, поверх которой накрутили уже всяких FSD, Atomic design и т.п. Что бы избежать всего этого ужаса, достаточно чуть чуть пораскинуть мозгами и почитать умных книжек. К примеру, для реализации mvvm паттерна, можно взять сигналы или rxjs, написать хук биндер, который свяжет стейт jsx и данные модели и будет вам счастье. вы сможете писать отдельно бизнеслогику не перегружая реакт. Добившись того что большая часть проблем описанных в статье просто пропадет
Стенд с потенциалом. Думал такой собрать в свое время, да все руки не доходили.
Согласен с автором, ощутил на себе как тесты экономят время и ресурсы. Я бы еще добавил, что существует тип проектов, как библиотеки, которые в принципе разрабатываются только через написание тестов.
Прикрутиш Dispose, и закроешь ее
Причем тут сервер? Раговор про фронтовое приложение,в его архитектуре так же есть бизнеслогика, она специффична именно клиенту, но она есть и она не должна быть в слое реакта.
Накидал пример кода как подружить реакт со сторонней либой, Всю реактивность можно запишнуть в DI контейнер и там сохранить бизнеслогику. вызывать апи клиенты, проводить валидации и тп. а из контейнера выставлять именно реактивные пропсы, таким образом на реакт слой прилетают только пропсы и колбеки. Все делается элементарно и не нужно ничего выдумывать. Вместо di контейнера вы можете использовать mvvm, тогда этот хук будет для него binder'ом, а модель может быть рукописным классом
в данном случае это не важно, важен сам факт успешного применения подхода. Все реактивные либы +- одинаковые, как и di контейнеры.
Всегде интересовал вопрос - что вы там такое делаете все, что вам так дико нехватает перформанса?? у вас там что пользователи заполняют формы быстрее чем реакт инпуты рендерит? вы где то на глаз замечаете эти сотые секунды задержки между вводом и ререндером?
Никто вам не мешает использовать для бизнеслогики стороннюю реактивность, от самописной до сигналов. если вы хотите заменить потроха реакта на [любая реактивная библиотека], то возникает вопрос - зачем? И предположу, что любой ваш агрумент будет сводится к тому что вы хотите замешать кучу лишний логики в слой отображения. Которой там быть не должно.
Хуки нужно воспринимать как промежуточное решение, я бы сказал - тестирование концепции, насколько я помню, скоро все сведется к одному хуку use. Если юзать compiler то против вообще можно будет забыть. Северные компоненты сильно упрощают жизнь, особенно если приложение работает на сервере. Так что формально там лишнего нет. Всё необходимое для рендера.
Почему это должно быть сложно? ангуляр живет с этим и проблем не наблюдается.
С каких пор использование инструмента по назначению это инновация? реакт это библиотека для рендера. Всегда было непонятно почему все считают его серебренной пулей и жалуются что в него не пичкают ненужным ему хламом.
Большинство людей которые пишут на реакте не понимают что это именно библиотека для отображения UI. Из за того что у них нет технического бекграунда(в большинстве своем это именно так и есть, реакт выбирают вкатуны из за низкого порога входа). Если вы хотите реализовать MV* паттерн, то нужно понять что реакт это именно V, т.е. в компоненты должны прилетать уже готовые данные. И многие не понимают как все собрать в кучу и делают все что предлагает npm. следовательно проект превращается в кладбище пакетов и жирнущую реализацию flux архитектуры, поверх которой накрутили уже всяких FSD, Atomic design и т.п.
Что бы избежать всего этого ужаса, достаточно чуть чуть пораскинуть мозгами и почитать умных книжек. К примеру, для реализации mvvm паттерна, можно взять сигналы или rxjs, написать хук биндер, который свяжет стейт jsx и данные модели и будет вам счастье. вы сможете писать отдельно бизнеслогику не перегружая реакт. Добившись того что большая часть проблем описанных в статье просто пропадет
все зависит от того что вы пишите. При написании сложных библиотек или фреймворков это все применяется.