универсальность есть если у вас есть системное видение в апи - я привел пример системы для реализации REST протокола. Мы используем JSON RPC - отлично все легло без напильника :)
нет вы не правильно поняли - слой API в приложении пишется один раз и больше никогда не изменяется. Он в соответствии с вашими соглашениями и ограничениями будет генерировать любые вызовы, которые вы попытаетесь вызвать на нем (объект Proxy в js позволяет для такого объекта делать вызовы не существующих методов - этот объект перехватывает эти вызовы и выполняет определенный код для них, который вы напишете).
В это же время typescript не позволит вам делать вызовы которых нет в интерфейсе API
При генерации API слоя или написания его руками - вы тратите ресурсы и время на них, слой API в приложении растет
В предложенном мною методе - вы просто на сервере из кода извлекаете типы и просто делитесь ими с фронтом - при изменениях в API при обновлении типов в коде могут возникнуть ошибки связанные с изменением вызовов API которые нужно исправить в приложении и всё ничего больше исправлять и изменять не нужно
Давайте по порядку - если мы говорим о компоненте Счетчик - мы так же передаем в него данные через свойства, а хук у нас используется в контейнере - у нас чистая архитектура в проекте - зачем контекст? контекст нам совсем не нужен в приложении! - где у нас с Zustand сложный и не понятный интерфейс - у нас все просто и очень понятно! - о какой концепции вы спрашиваете я так и не понял - напишите подробней
Попробуйте сформулировать вопрос в конструктивной форме а не в форме протеста и отрицания. Если вас интересует что и как реализовано в Zustand и почему он проще и быстрее - я готов с вами обсудить
И в этой статье также одни розовые сопли и никакой аналитики, сравнений с нормальными решениями типа MobX, чуть более сложных примеров, чем банальный каунтер, примеров масштабирования системы, её гибкости.
Извините, но после таких фраз обсуждать нечего да и не хочется особо Такие безапелляционные заявления - это верх пренебрежения, боязнь нового и попахивает не компетентностью
У нас большое приложение больше 2х лет работы и ни одного каунтера - сплошь сложные структуры данных и сложная логика.
В общем после таких заявлений - одни негативные эмоции возникают (
> Декомпозиция бизнес логики на составляющие и её инкапсуляция
ваша "декомпозиция" приводит к композиции сложности и не надежности приложения (об этом написано в статье) - попробуйте в базах данных кому-нибудь рассказать что вы хотите часть базы данных "декомпозировать" - вас сразу же "декомпозируют" подальше от нее.
> Повышение реиспользуемости разных частей приложения
вот тут просто набор слов - не понятно как на него реагировать
> Увеличение связность и уменьшение зацепления (а в общих сторах вся всегда очень зацеплено и слабо связано)
вообще мимо - это относится к коду но не к данным
> Code Splitting
не нужно путать код сплиттинг с разбиением данных на хранилища - это вещи абсолютно разного порядка. Асинхронно загружаемых бандлов может быть сколько угодно, но какое отношение они имеют к хранилищу данных, к целостности и не противоречивости их??
> Поддерживаемость
вот как раз поддерживаемость одного хранилища в разы выше чем кучи хранилищ с непрозрачной логикой связи, с разнонаправленными потоками обновления данных и тд и тп - еще раз повторюсь в статье этот кейс описан
> Производительность о какой производительности вы ведете речь - пожалуйста код в студию с измерениями!
Такое ощущение что вы боитесь потерять работу потому что ваш MobX задвинут и возьмут в работу что-то более простое, легкое и гибкое
В общем не пишите пожалуйста больше в таком пренебрежительном стиле и тональности - вы вызываете такими комментами только негативные эмоции.
Если вас интересуют технические аспекты - задавайте вопросы - я готов обсуждать
в статье я написал, что компания может оформить код в отдельную библиотеку и использовать на разных проектах, но написать отдельную публичную библиотеку для всех сложно - требование к API в каждой компании своё - у кого-то REST, у кого-то RPC и т.д.
а как фронт по вашему должен узнать о сделанных изменениях?
- публиковать код, реализующий логику API, но это затраты на генерацию кода который будет расти в объеме с ростом количества используемых методов. после обновления кода - менять вызовы API в приложении
- второй вариант - написать Proxy объект и обновлять только типы (код в слое API не меняется вообще никогда - нет необходимости генерировать или менять его) После обновления типов - менять вызовы API в приложении
Бэк описал это в typescript и опубликовал, к примеру:
newMethod: (params: Params) => ResultType;
разработчик приложения обновляет пакет с описанием интерфейса и в приложении просто делает вызов этого метода (IDE подскажет правильный синтаксис метода и типы параметров)
const result = await api.newMethod({... params ...});
всё! Proxy все сделает за вас по указанным в нем правилам!
В статье в коде все уже написано - попробуйте поиграться с кодом и у вас все станет на свои места
вот к примеру описание гипотетического API для taskList примера
да уж тяжелый случай ))
чем лучше - тем что вам MobX просто нравится? :)
это означает что это лучше для вас но не для остальных )))
завтра выложу код - попробуете руками и станет все на свои места
вам вот сюда https://habr.com/ru/articles/798887/comments/#comment_26591991 - я на подобный вопрос выше отыечал
универсальность есть если у вас есть системное видение в апи - я привел пример системы для реализации REST протокола. Мы используем JSON RPC - отлично все легло без напильника :)
у нас на проекте все работает и горя не знаем
нет вы не правильно поняли - слой API в приложении пишется один раз и больше никогда не изменяется. Он в соответствии с вашими соглашениями и ограничениями будет генерировать любые вызовы, которые вы попытаетесь вызвать на нем (объект Proxy в js позволяет для такого объекта делать вызовы не существующих методов - этот объект перехватывает эти вызовы и выполняет определенный код для них, который вы напишете).
В это же время typescript не позволит вам делать вызовы которых нет в интерфейсе API
При генерации API слоя или написания его руками - вы тратите ресурсы и время на них, слой API в приложении растет
В предложенном мною методе - вы просто на сервере из кода извлекаете типы и просто делитесь ими с фронтом - при изменениях в API при обновлении типов в коде могут возникнуть ошибки связанные с изменением вызовов API которые нужно исправить в приложении и всё ничего больше исправлять и изменять не нужно
я правда не понял ваш вопрос про концепции
сформулируйте его более понятно и я смогу конструктивно ответить
согласен - это может пугать, но у нас есть хороший полицейский в виде typescript - он не даст разгуляться фулигану :)
Давайте по порядку
- если мы говорим о компоненте Счетчик - мы так же передаем в него данные через свойства, а хук у нас используется в контейнере - у нас чистая архитектура в проекте
- зачем контекст? контекст нам совсем не нужен в приложении!
- где у нас с Zustand сложный и не понятный интерфейс - у нас все просто и очень понятно!
- о какой концепции вы спрашиваете я так и не понял - напишите подробней
Попробуйте сформулировать вопрос в конструктивной форме а не в форме протеста и отрицания. Если вас интересует что и как реализовано в Zustand и почему он проще и быстрее - я готов с вами обсудить
Извините, но после таких фраз обсуждать нечего да и не хочется особо
Такие безапелляционные заявления - это верх пренебрежения, боязнь нового и попахивает не компетентностью
У нас большое приложение больше 2х лет работы и ни одного каунтера - сплошь сложные структуры данных и сложная логика.
В общем после таких заявлений - одни негативные эмоции возникают (
> Декомпозиция бизнес логики на составляющие и её инкапсуляция
ваша "декомпозиция" приводит к композиции сложности и не надежности приложения (об этом написано в статье) - попробуйте в базах данных кому-нибудь рассказать что вы хотите часть базы данных "декомпозировать" - вас сразу же "декомпозируют" подальше от нее.
> Повышение реиспользуемости разных частей приложения
вот тут просто набор слов - не понятно как на него реагировать
> Увеличение связность и уменьшение зацепления (а в общих сторах вся всегда очень
зацеплено и слабо связано)
вообще мимо - это относится к коду но не к данным
> Code Splitting
не нужно путать код сплиттинг с разбиением данных на хранилища - это вещи абсолютно разного порядка. Асинхронно загружаемых бандлов может быть сколько угодно, но какое отношение они имеют к хранилищу данных, к целостности и не противоречивости их??
> Поддерживаемость
вот как раз поддерживаемость одного хранилища в разы выше чем кучи хранилищ с непрозрачной логикой связи, с разнонаправленными потоками обновления данных и тд и тп - еще раз повторюсь в статье этот кейс описан
> Производительность
о какой производительности вы ведете речь - пожалуйста код в студию с измерениями!
Такое ощущение что вы боитесь потерять работу потому что ваш MobX задвинут и возьмут в работу что-то более простое, легкое и гибкое
В общем не пишите пожалуйста больше в таком пренебрежительном стиле и тональности - вы вызываете такими комментами только негативные эмоции.
Если вас интересуют технические аспекты - задавайте вопросы - я готов обсуждать
код, что написан в статье демонстрирует это - возьмите его и попробуйте выполнить в консоли
Попробуйте делать вызовы не существующих методов ...
Позже я сделаю демо-проект и ссылку прикреплю к статье
в статье я написал, что компания может оформить код в отдельную библиотеку и использовать на разных проектах, но написать отдельную публичную библиотеку для всех сложно - требование к API в каждой компании своё - у кого-то REST, у кого-то RPC и т.д.
у нас это провайдер API хранится в файле
src/providers/api/index.tsэтот код хранится на клиенте - это API слой приложения
или вы имели в виду что-то другое?
ради одного такого комментария стоит писать статьи - спасибо, что хоть кому-то пригодилась идея!
начал было разочаровываться в сообществе - минусуют без аргументов (скорее всего не поняли идеи)
в этом то и большой кайф, что не нужно ничего менять - прокси может делать вызовы не существующих методов!!!
Почитайте про возможности Proxy в js
а как фронт по вашему должен узнать о сделанных изменениях?
- публиковать код, реализующий логику API, но это затраты на генерацию кода который будет расти в объеме с ростом количества используемых методов. после обновления кода - менять вызовы API в приложении
- второй вариант - написать Proxy объект и обновлять только типы (код в слое API не меняется вообще никогда - нет необходимости генерировать или менять его) После обновления типов - менять вызовы API в приложении
Бэк описал это в typescript и опубликовал, к примеру:
newMethod: (params: Params) => ResultType;разработчик приложения обновляет пакет с описанием интерфейса и в приложении просто делает вызов этого метода (IDE подскажет правильный синтаксис метода и типы параметров)
const result = await api.newMethod({... params ...});
всё! Proxy все сделает за вас по указанным в нем правилам!
В статье в коде все уже написано - попробуйте поиграться с кодом и у вас все станет на свои места
вот к примеру описание гипотетического API для taskList примера
export interface Api {getTasks: () => Promise<JsonRpcResponse<TasksData>>;createTask: (task: NewTask) => Promise<JsonRpcResponse<Task>>;updateTask: (task: Task) => Promise<JsonRpcResponse<Task>>;deleteTask: (task: Task) => Promise<JsonRpcResponse<Task>>;clearTasks: () => Promise<JsonRpcResponse<Task[]>>;}
в коде приложения пишем методы вызова
const api = createApi('https://your-domain/api');
const result = await api.createTask({ title: 'newTask' });
...
const result = await api.deleteTask({ id: 1, title: 'newTask' });
ну а кто же по вашему должен писать техдокументацию на этот код?
Кто же кроме тех кто писал этот код знает что там написано?
Конечно же кто пишет код - тот и должен писать техдокументацию.
Не можем же мы менеджера по клинингу все время напрягать писать нам техдокументацию - так он обидится и некому будет убирать офис!? :)