нет не будет ни на байт распухать прокси-слой - там нет методов АПИ - они появляются только в рантайме в момент их вызова в приложении (псомотрите демо проект)
да, тот кто пишет код - тот его и описывает в типах - извините фронтэндщики не телепаты! )
да я же вам написал - никаких сложностей - как и при генеративном подходе как и при ручном так и при использовании Proxy вам в любом случае в коде приложения нужно заменить удаленный вызов на 2 новых.
В 2х первых вариантах - вам еще нужно эти изменения привнести в АПИ слой - в моем варианте этого не нужно делать
надеюсь мы пришли к общему пониманию ) прошу прощения, но по вышезаданным вопросам я не уловил акцент
если убрать не свойственную АПИ логику из АПИ слоя - все вопросы решаются легко, а так получается что бизнес-логика последовательности вызова протекает в сервисный слой который ничего не должен знать о работе приложения вообще
ну если это относится к логике порядка вызовов в приложении - ее нужно реализовывать в любом варианте реализации слоя АПИ а если вы хотите сказать что это было в слое АПИ - тогда ваш слой АПИ выполняет не свойственные ему функции - он знает о чужой логике и правильнее было бы вынести эту логику либо на сервер либо в приложение где слой юзкейсов знает о таких вещах
слой АПИ в приложении должен выполнять только транспортную роль и должен быть простым передастом )
по поводу способа передачи параметров одним объектом или несколькими свойствами - это уже на вкус
как можете видеть никаких проблем с тестированием но на самом деле - это наивная реализация - у нас слоеная архитектура и в контейнерах мы вызываем уже не стор а юзкейсы
так как у вас прекратил существование common1 и апоявились 2 новых метода: entity2 и entity3 вам соответственно в интерфейсе API нужно удалить описание старого метода и добавить описание 2х новых - все!
Когда типы будут обновлены на клиенте - появится ошибка в приложении на удаленном методе, что такого метода не существует - удаляете в приложении старый вызов и делаете 2 новых
вы предлагаете распухающий со временем код прослойки который нужно постоянно генерировать или править руками я же предлагаю 0 изменения кода прослойки и ничего не нужно генерировать и ничего не нужно в ней править
да, и тестировать в ней тоже нечего - тестируется сервер
нет не верно вы меня поняли! я же написал в рекомендациях, что вопреки документации не нужно писать методы в стор - наоборот их лучше хранить отдельно, каждый метод в своем модуле - там он легче читается и тестируется
ну почему же никто не читает про опыт который был уже в индустрии до того как вы пришли в нее!?? ) Был у нас MVC а затем и библиотеки типа Backbone когда в приложении были сотни таких атомов в иде моделей и коллекций. Это приводило к жути на проекте - куча непрозрачного кода для связи этих атомом между собой, направления потоков обновлений и их последовательность превращалась в хаос - это нигде явно не видно только руками по всему коду!!! В конце концов это приводило постоянно к зацикливаниям изменений для нахождения которых требовались адские усилия - брейкпоинты приходилось ставить по всему коду приложения
Вот почему индустрия сбежала от MVC во FLUX а затем доработали его в REDUX! Если вам хочется понаступать на эти грабли - всегда пожалуйста :)
я понял вопрос смотрите у нас, как я и написал ниже в рекомендация, все связанные структуры данных хранятся в одном сторе, поэтому когда вы вызываете хук `useAppStore` вы получаете доступ ко всем структурам в сторе
В вашем случае несколько каунтеров были бы в одном сторе Ваш вопрос раскрывает проблемы многосторных приложений - когда их становится много - ими становится сложно управлять, их везде нужно таскать толпой, логика связей размазана по коду, изменения в одном сторе могут приводить к изменениям в другом сторе и так далее по цепочке и как часто это было ив MVC и во фреймворках типа Backbone (где были сотни таких сторов в виде моделей) это всегда приводило к зацикливанию изменений найти которое было еще тем адским трудом
Если я не ответил на ваш вопрос - уточните я попробую объяснить
бэки при сборке кода автоматом от tsc получают описание интерфейса и оформляют его в новую версию пакета Фронты импортируют только этот интерфейс и ничего не исправляют кроме изменившихся вызовов в приложении Прокси объект не меняется никогда
у нас профит в том, что данный подход хорошо ложится на используемый у нас протокол JSON RPC и мы ничего не пишем и не генерируем - в процессе сборки бэк получает сгенерированный tsc интерфейс и отправляет его в пакет. Фронты импортируют новую версию и патчат только код приложения
нет не будет ни на байт распухать прокси-слой - там нет методов АПИ - они появляются только в рантайме в момент их вызова в приложении (псомотрите демо проект)
да, тот кто пишет код - тот его и описывает в типах - извините фронтэндщики не телепаты! )
да я же вам написал - никаких сложностей - как и при генеративном подходе как и при ручном так и при использовании Proxy вам в любом случае в коде приложения нужно заменить удаленный вызов на 2 новых.
В 2х первых вариантах - вам еще нужно эти изменения привнести в АПИ слой - в моем варианте этого не нужно делать
надеюсь мы пришли к общему пониманию )
прошу прощения, но по вышезаданным вопросам я не уловил акцент
если убрать не свойственную АПИ логику из АПИ слоя - все вопросы решаются легко, а так получается что бизнес-логика последовательности вызова протекает в сервисный слой который ничего не должен знать о работе приложения вообще
ну если это относится к логике порядка вызовов в приложении - ее нужно реализовывать в любом варианте реализации слоя АПИ
а если вы хотите сказать что это было в слое АПИ - тогда ваш слой АПИ выполняет не свойственные ему функции - он знает о чужой логике и правильнее было бы вынести эту логику либо на сервер либо в приложение где слой юзкейсов знает о таких вещах
слой АПИ в приложении должен выполнять только транспортную роль и должен быть простым передастом )
посмотрите демо проект
у нас тоже все по феншую
function Counter({count, increment}: {count: number, increment: ()=>void}) {return <button onClick={store.increment}>{store.count}</button>;;
}
function CounterContainer() {const { count, increment} = useAppStore(state=> state.counter)
return <Counter count={count} increment={increment}>;
}
по поводу способа передачи параметров одним объектом или несколькими свойствами - это уже на вкус
как можете видеть никаких проблем с тестированием
но на самом деле - это наивная реализация - у нас слоеная архитектура и в контейнерах мы вызываем уже не стор а юзкейсы
так как у вас прекратил существование common1 и апоявились 2 новых метода: entity2 и entity3 вам соответственно в интерфейсе API нужно удалить описание старого метода и добавить описание 2х новых - все!
Когда типы будут обновлены на клиенте - появится ошибка в приложении на удаленном методе, что такого метода не существует - удаляете в приложении старый вызов и делаете 2 новых
АПИ слой на клиенте не трогаете и не меняете
вы предлагаете распухающий со временем код прослойки который нужно постоянно генерировать или править руками я же предлагаю 0 изменения кода прослойки и ничего не нужно генерировать и ничего не нужно в ней править
да, и тестировать в ней тоже нечего - тестируется сервер
вы не правы - посмотрите прикрепленный демо проект с описанием действий
const UseAppStore = create(() =>{
catsCounter : 0,
dogsCounter: 0,
....
})
function Counter(){
// const catsCounter = UseAppStore(state => state.catsCounter)
const dogsCounter = UseAppStore(state => state.dogsCounter)
...
}
я правильно понял задачу что нужно выбрать один из каунтеров?
нет не верно вы меня поняли!
я же написал в рекомендациях, что вопреки документации не нужно писать методы в стор - наоборот их лучше хранить отдельно, каждый метод в своем модуле - там он легче читается и тестируется
В сторе хранить нужно только структуры данных
это точно причем они налетают толпой и начинают жутко минусовать - это у них комплекс какой-то прям
я уже их называю MobX маньяками ))
ну почему же никто не читает про опыт который был уже в индустрии до того как вы пришли в нее!?? )
Был у нас MVC а затем и библиотеки типа Backbone когда в приложении были сотни таких атомов в иде моделей и коллекций. Это приводило к жути на проекте - куча непрозрачного кода для связи этих атомом между собой, направления потоков обновлений и их последовательность превращалась в хаос - это нигде явно не видно только руками по всему коду!!! В конце концов это приводило постоянно к зацикливаниям изменений для нахождения которых требовались адские усилия - брейкпоинты приходилось ставить по всему коду приложения
Вот почему индустрия сбежала от MVC во FLUX а затем доработали его в REDUX!
Если вам хочется понаступать на эти грабли - всегда пожалуйста :)
я понял вопрос
смотрите у нас, как я и написал ниже в рекомендация, все связанные структуры данных хранятся в одном сторе, поэтому когда вы вызываете хук `useAppStore` вы получаете доступ ко всем структурам в сторе
В вашем случае несколько каунтеров были бы в одном сторе
Ваш вопрос раскрывает проблемы многосторных приложений - когда их становится много - ими становится сложно управлять, их везде нужно таскать толпой, логика связей размазана по коду, изменения в одном сторе могут приводить к изменениям в другом сторе и так далее по цепочке и как часто это было ив MVC и во фреймворках типа Backbone (где были сотни таких сторов в виде моделей) это всегда приводило к зацикливанию изменений найти которое было еще тем адским трудом
Если я не ответил на ваш вопрос - уточните я попробую объяснить
?
бэки при сборке кода автоматом от tsc получают описание интерфейса и оформляют его в новую версию пакета
Фронты импортируют только этот интерфейс и ничего не исправляют кроме изменившихся вызовов в приложении
Прокси объект не меняется никогда
ну почему никто не читает статью! )))
там написано что прокси пишется только один раз вначале и не меняется больше никогда!
меняются только типы
ну как бы мягко сказать что мы классы не используем совсем
у нас профит в том, что данный подход хорошо ложится на используемый у нас протокол JSON RPC и мы ничего не пишем и не генерируем - в процессе сборки бэк получает сгенерированный tsc интерфейс и отправляет его в пакет.
Фронты импортируют новую версию и патчат только код приложения
демка: https://github.com/budarin/proxy-api-demo
добавил демо проект https://github.com/budarin/proxy-api-demo