рад, что попробовали и то и другое и можете объективно оценить! ( только переживаю за вас - сейчас свидетели MobX налетят на вас толпой и будут хэйтить и минусовать ? )
задайте вопрос в разделе Дискуссии проекта - Дайши Като (маинтейнер) общительный парень и оперативно отвечает на все вопросы
я о такой erp системе даже и не слышал так что уж извините - идея ко мне пришла когда рассматривая кучу всяких библиотек с Proxy.У нас так же реализовано все это на json rpc который мы используем уже долгие годы
А за информацию - спасибо! Это дополнительно подтверждает, что мое решение верное!
сразу по диалогу можно распознать бэкэндеров и фронтов :) SSR или CSR - всё зависит от типа приложения К примеру: поисковики ну никак нормально при помощи CSR не реализуешь и напротив - приложение с интенсивной работой с данными и большим деревом роутинга реализованное на SSR - будет кошмаром для пользователя - ждать при каждом нажатии перерисовки страницы по секунде а то и более на мобильном соединении у любого пользователя не хватит терпения. Как всегда истина где-то по середине - нужно искать баланс
Жаль мне не подойдет - мне медведь на ухо наступил :) Я использую в качестве пароля фразы из стихов или песен - легко запоминаются и плохо взламываются
сектанты секты свидетелей MobX - отcnаньте! Не вступлю я в вашу секту, где людей превращают в агрессивных, токсичных и навязчивых личностей!
Я в жизни не встречал таких негативно настроенных к другим людям сектантов! Ни разу не слышал наездов от любителей Recoil, Valtio, Restate и всех остальных стет-менеджеров.
Нормальные люди спокойно обсуждают технические особенности того или иного инструмента! Такое агрессивное негативное и токсичное поведение встретил только от свидетелей пришествия MobX!
согласен - найти прям огненную фразу которая бы расставила все точки над Ё достаточно сложно сразу - порой приходится пройти кучу споров и объяснений чтобы найти точную формулировку!
Спасибо что помогаете найти смысл - добавлю ее в текст
(но данное решение и правда позволяет избегать постоянного переписывания кода слоя АПИ в приложении тоже ? )
вообще если говорить про логику, а это есть бизнес-логика = домен, то как минимум все доменные сущности должны быть в сторе домена и там же методы стора по изменению и управлению доменными сущностями, а в слое пользовательских сценариев уже должна располагаться логика приложения которая и должна вызываться на ваших страницах
как как? да все придурки до вас были - так и писали код. у всех руки были кривые все специально циклы писали - нравилось это всем! а как вы считаете? умные же все только сейчас в индустрию пришли а раньше одни криворукие были )
нет уж спасибо - меня Zustand своей простотой и гибкостью полностью удовлетворяет!
Я уже начинаю бояться любителей MobX - они все агрессивные токсичные и навязчивые! набежали написали фигни, нахамили, наставили минусов и постоянно уговаривают перейти на MobX как в секту ! Это просто уже подозрительно! Не собираюсь я в такую секту вступать - я хочу остаться нормальным )
вы часто на проектах наблюдаете перезод с одного протокола на другой? ну случится этот переход один ну максимум 2 раза за все время существования компании - тяжело переписать меньше килобайта кода? )
вопрос в коде - он не нужен! вы генерируете кучу методов выполняющих по сути одно и тоже но их много и они много весят! в замен вам предлагается генерить лишь интерфейс на typescript а всю кучу однотипного кода свернуть до кода одного proxy-объекта который весит меньше килобайта приэтом будет сэкономлено тысячи часов процессорного времени на генерации кода а так же уменьшится нагрузка на сервера компании благодаря меньшему размеру бандлов
я уже отвечал на подобный вопрос - если АПИ не придерживается никакой системы - да такой подход не подойдет! Данный подход предполагает что АПИ имеет четкие правила и ограничения и они системны
вы абсолютно правы - слой АПИ в приложении должен быть тупым передастом - его один раз протестировали что он выполняет свои функции по приёму/передаче данных в требуемых условиях и всё! всё остальное его не касается - это не его зона отвественности
Если вы размажете бизнес логику и на этот слой - ну тогда миритесь со сложностью своего проекта и частыми багами где что-то изменили в одном месте в сотне других которые размазаны везде - забыли
я понял вас - генерировать интерфейс кому-то придется а кому-то и нет - все зависит от того на чем пишут и как мы про разное "пухнуть" говорили - я имел в виду что код апи слоя никак не будет изменятся а типы в конечном коде не участвуют и на размер бандла не влияют - могут и попухнуть немного )
в НАШЕМ сообществе не места хейту и дискриминации по цвету штанов и не абсолютному знанию материала - все мы учимся постоянно ?
Отличная статья! Спасибо.
рад, что попробовали и то и другое и можете объективно оценить!
( только переживаю за вас - сейчас свидетели MobX налетят на вас толпой и будут хэйтить и минусовать ? )
задайте вопрос в разделе Дискуссии проекта - Дайши Като (маинтейнер) общительный парень и оперативно отвечает на все вопросы
в веб проектах erp системы не используются
я о такой erp системе даже и не слышал так что уж извините - идея ко мне пришла когда рассматривая кучу всяких библиотек с Proxy.У нас так же реализовано все это на json rpc который мы используем уже долгие годы
А за информацию - спасибо! Это дополнительно подтверждает, что мое решение верное!
сразу по диалогу можно распознать бэкэндеров и фронтов :)
SSR или CSR - всё зависит от типа приложения
К примеру: поисковики ну никак нормально при помощи CSR не реализуешь и напротив - приложение с интенсивной работой с данными и большим деревом роутинга реализованное на SSR - будет кошмаром для пользователя - ждать при каждом нажатии перерисовки страницы по секунде а то и более на мобильном соединении у любого пользователя не хватит терпения.
Как всегда истина где-то по середине - нужно искать баланс
Жаль мне не подойдет - мне медведь на ухо наступил :)
Я использую в качестве пароля фразы из стихов или песен - легко запоминаются и плохо взламываются
да, спасибо за подсказку - нашел в маппинге было не верно - теорию то точно знаю, но писал за один вечер быстро и переставил местами не нарочно :)
перепроверил у ИИ - нет, всё вроде бы верно
POSTиспользуется для создания новой сущности в коллекции ресурсов.PUTиспользуется для полного обновления существующей сущности или создания новой по определенному URI, если она еще не существует.PATCHприменяется для частичного обновления существующей сущности.сектанты секты свидетелей MobX - отcnаньте! Не вступлю я в вашу секту, где людей превращают в агрессивных, токсичных и навязчивых личностей!
Я в жизни не встречал таких негативно настроенных к другим людям сектантов! Ни разу не слышал наездов от любителей Recoil, Valtio, Restate и всех остальных стет-менеджеров.
Нормальные люди спокойно обсуждают технические особенности того или иного инструмента! Такое агрессивное негативное и токсичное поведение встретил только от свидетелей пришествия MobX!
Ужас! Чур меня, Чур!
согласен - найти прям огненную фразу которая бы расставила все точки над Ё достаточно сложно сразу - порой приходится пройти кучу споров и объяснений чтобы найти точную формулировку!
Спасибо что помогаете найти смысл - добавлю ее в текст
(но данное решение и правда позволяет избегать постоянного переписывания кода слоя АПИ в приложении тоже ? )
теоретически только тогда когда меняем систему требований к АПИ
вполне возможно - посмотрю
вообще если говорить про логику, а это есть бизнес-логика = домен, то как минимум все доменные сущности должны быть в сторе домена и там же методы стора по изменению и управлению доменными сущностями, а в слое пользовательских сценариев уже должна располагаться логика приложения которая и должна вызываться на ваших страницах
как как? да все придурки до вас были - так и писали код. у всех руки были кривые все специально циклы писали - нравилось это всем! а как вы считаете? умные же все только сейчас в индустрию пришли а раньше одни криворукие были )
нет уж спасибо - меня Zustand своей простотой и гибкостью полностью удовлетворяет!
Я уже начинаю бояться любителей MobX - они все агрессивные токсичные и навязчивые! набежали написали фигни, нахамили, наставили минусов и постоянно уговаривают перейти на MobX как в секту ! Это просто уже подозрительно!
Не собираюсь я в такую секту вступать - я хочу остаться нормальным )
вы часто на проектах наблюдаете перезод с одного протокола на другой?
ну случится этот переход один ну максимум 2 раза за все время существования компании - тяжело переписать меньше килобайта кода? )
вопрос в коде - он не нужен! вы генерируете кучу методов выполняющих по сути одно и тоже но их много и они много весят!
в замен вам предлагается генерить лишь интерфейс на typescript а всю кучу однотипного кода свернуть до кода одного proxy-объекта который весит меньше килобайта приэтом будет сэкономлено тысячи часов процессорного времени на генерации кода а так же уменьшится нагрузка на сервера компании благодаря меньшему размеру бандлов
я уже отвечал на подобный вопрос - если АПИ не придерживается никакой системы - да такой подход не подойдет!
Данный подход предполагает что АПИ имеет четкие правила и ограничения и они системны
вы абсолютно правы - слой АПИ в приложении должен быть тупым передастом - его один раз протестировали что он выполняет свои функции по приёму/передаче данных в требуемых условиях и всё!
всё остальное его не касается - это не его зона отвественности
Если вы размажете бизнес логику и на этот слой - ну тогда миритесь со сложностью своего проекта и частыми багами где что-то изменили в одном месте в сотне других которые размазаны везде - забыли
я понял вас - генерировать интерфейс кому-то придется а кому-то и нет - все зависит от того на чем пишут и как
мы про разное "пухнуть" говорили - я имел в виду что код апи слоя никак не будет изменятся а типы в конечном коде не участвуют и на размер бандла не влияют - могут и попухнуть немного )
название придумал ИИ )
я просил чтобы оно было привлекательным для чтения - вот он и придумал такую провокацию )