в начале всегда возникает не приятие - новое не понятное, но если понять - то потом не оторвешь за уши :) старый подход предлагает генерировать тонны однотипного кода - мой метод предлагает его вообще не генерировать и облегчить жизнь фронтендерам и юзерам, но все в начале протестуют - не хотят ни добра фронтэндерам ни радости юзерам ну потому что привыкли уже по-старинке)) а зачем что-то менять? ))
нет не предлагаю - я предлагаю вам как и раньше при помощи инструментов того же swagger генерировать только описание интерфейса на typescript! Для бэкэндеров ничего в процессе не меняется, а вот во фронтенде - приложение получает большой плюс в виде отсутствия пустого кода
встроенные методы не приветствую и не использую (см п.3 рекомендации) но в коде за api скрывается интерфейс pub/sub объекта (реального хранилища данных)
эти методы пробрасываются для прямых подписок и прямых манипуляций с данными в хранилище (когда внутри метода хранилища какие-то объекты могут подписываться на обновление данных и реагировать) - думаю что это для крайне экзотических ситуаций и в 99 .9% случаев он не используется - достаточно предоставляемых методов get и set
методы get и set - просто синонимы методов getState и setState
пример с set есть либо в readme либо в доке - точно помню
в статью, я думаю не нужно включать, статья получится копией документации - смысл статьи показать основные возможности и заинтересовать, а детали уже всегда можно в доке найти
рад, что попробовали и то и другое и можете объективно оценить! ( только переживаю за вас - сейчас свидетели MobX налетят на вас толпой и будут хэйтить и минусовать ? )
задайте вопрос в разделе Дискуссии проекта - Дайши Като (маинтейнер) общительный парень и оперативно отвечает на все вопросы
я о такой erp системе даже и не слышал так что уж извините - идея ко мне пришла когда рассматривая кучу всяких библиотек с Proxy.У нас так же реализовано все это на json rpc который мы используем уже долгие годы
А за информацию - спасибо! Это дополнительно подтверждает, что мое решение верное!
сразу по диалогу можно распознать бэкэндеров и фронтов :) SSR или CSR - всё зависит от типа приложения К примеру: поисковики ну никак нормально при помощи CSR не реализуешь и напротив - приложение с интенсивной работой с данными и большим деревом роутинга реализованное на SSR - будет кошмаром для пользователя - ждать при каждом нажатии перерисовки страницы по секунде а то и более на мобильном соединении у любого пользователя не хватит терпения. Как всегда истина где-то по середине - нужно искать баланс
Жаль мне не подойдет - мне медведь на ухо наступил :) Я использую в качестве пароля фразы из стихов или песен - легко запоминаются и плохо взламываются
сектанты секты свидетелей MobX - отcnаньте! Не вступлю я в вашу секту, где людей превращают в агрессивных, токсичных и навязчивых личностей!
Я в жизни не встречал таких негативно настроенных к другим людям сектантов! Ни разу не слышал наездов от любителей Recoil, Valtio, Restate и всех остальных стет-менеджеров.
Нормальные люди спокойно обсуждают технические особенности того или иного инструмента! Такое агрессивное негативное и токсичное поведение встретил только от свидетелей пришествия MobX!
согласен - найти прям огненную фразу которая бы расставила все точки над Ё достаточно сложно сразу - порой приходится пройти кучу споров и объяснений чтобы найти точную формулировку!
Спасибо что помогаете найти смысл - добавлю ее в текст
(но данное решение и правда позволяет избегать постоянного переписывания кода слоя АПИ в приложении тоже ? )
вообще если говорить про логику, а это есть бизнес-логика = домен, то как минимум все доменные сущности должны быть в сторе домена и там же методы стора по изменению и управлению доменными сущностями, а в слое пользовательских сценариев уже должна располагаться логика приложения которая и должна вызываться на ваших страницах
Понятно! Вы как и все остальные минусующие бэкэндеры прочитали заголовок и максимум 1й абзац и статью не прочли и кинулись писать гневный коммент ))
Вся статья и все комменты о том что не нужно будет при моем подходе НИКОГДА БОЛЬШЕ В ЖИЗНИ писать/генерировать код для клиента!!! )
в начале всегда возникает не приятие - новое не понятное, но если понять - то потом не оторвешь за уши :)
старый подход предлагает генерировать тонны однотипного кода - мой метод предлагает его вообще не генерировать и облегчить жизнь фронтендерам и юзерам, но все в начале протестуют - не хотят ни добра фронтэндерам ни радости юзерам ну потому что привыкли уже по-старинке)) а зачем что-то менять? ))
нет не предлагаю - я предлагаю вам как и раньше при помощи инструментов того же swagger генерировать только описание интерфейса на typescript!
Для бэкэндеров ничего в процессе не меняется, а вот во фронтенде - приложение получает большой плюс в виде отсутствия пустого кода
писать на сервере заголовки CSP для страницы
привет!
встроенные методы не приветствую и не использую (см п.3 рекомендации) но в коде за api скрывается интерфейс pub/sub объекта (реального хранилища данных)
interface StoreApi<T> {setState: SetStateInternal<T>;getState: () => T;getInitialState: () => T;subscribe: (listener: (state: T, prevState: T) => void) => () => void;}
эти методы пробрасываются для прямых подписок и прямых манипуляций с данными в хранилище (когда внутри метода хранилища какие-то объекты могут подписываться на обновление данных и реагировать) - думаю что это для крайне экзотических ситуаций и в 99 .9% случаев он не используется - достаточно предоставляемых методов get и set
методы get и set - просто синонимы методов
getStateиsetStateпример с set есть либо в readme либо в доке - точно помню
в статью, я думаю не нужно включать, статья получится копией документации - смысл статьи показать основные возможности и заинтересовать, а детали уже всегда можно в доке найти
Вот это жесткие реалии жизни :)
Молодцы!
отличная статья! спасибо!
очень нравится стиль - это куда интереснее и познавательнее чем сухие доки
в НАШЕМ сообществе не места хейту и дискриминации по цвету штанов и не абсолютному знанию материала - все мы учимся постоянно ?
Отличная статья! Спасибо.
рад, что попробовали и то и другое и можете объективно оценить!
( только переживаю за вас - сейчас свидетели MobX налетят на вас толпой и будут хэйтить и минусовать ? )
задайте вопрос в разделе Дискуссии проекта - Дайши Като (маинтейнер) общительный парень и оперативно отвечает на все вопросы
в веб проектах erp системы не используются
я о такой erp системе даже и не слышал так что уж извините - идея ко мне пришла когда рассматривая кучу всяких библиотек с Proxy.У нас так же реализовано все это на json rpc который мы используем уже долгие годы
А за информацию - спасибо! Это дополнительно подтверждает, что мое решение верное!
сразу по диалогу можно распознать бэкэндеров и фронтов :)
SSR или CSR - всё зависит от типа приложения
К примеру: поисковики ну никак нормально при помощи CSR не реализуешь и напротив - приложение с интенсивной работой с данными и большим деревом роутинга реализованное на SSR - будет кошмаром для пользователя - ждать при каждом нажатии перерисовки страницы по секунде а то и более на мобильном соединении у любого пользователя не хватит терпения.
Как всегда истина где-то по середине - нужно искать баланс
Жаль мне не подойдет - мне медведь на ухо наступил :)
Я использую в качестве пароля фразы из стихов или песен - легко запоминаются и плохо взламываются
да, спасибо за подсказку - нашел в маппинге было не верно - теорию то точно знаю, но писал за один вечер быстро и переставил местами не нарочно :)
перепроверил у ИИ - нет, всё вроде бы верно
POSTиспользуется для создания новой сущности в коллекции ресурсов.PUTиспользуется для полного обновления существующей сущности или создания новой по определенному URI, если она еще не существует.PATCHприменяется для частичного обновления существующей сущности.сектанты секты свидетелей MobX - отcnаньте! Не вступлю я в вашу секту, где людей превращают в агрессивных, токсичных и навязчивых личностей!
Я в жизни не встречал таких негативно настроенных к другим людям сектантов! Ни разу не слышал наездов от любителей Recoil, Valtio, Restate и всех остальных стет-менеджеров.
Нормальные люди спокойно обсуждают технические особенности того или иного инструмента! Такое агрессивное негативное и токсичное поведение встретил только от свидетелей пришествия MobX!
Ужас! Чур меня, Чур!
согласен - найти прям огненную фразу которая бы расставила все точки над Ё достаточно сложно сразу - порой приходится пройти кучу споров и объяснений чтобы найти точную формулировку!
Спасибо что помогаете найти смысл - добавлю ее в текст
(но данное решение и правда позволяет избегать постоянного переписывания кода слоя АПИ в приложении тоже ? )
теоретически только тогда когда меняем систему требований к АПИ
вполне возможно - посмотрю
вообще если говорить про логику, а это есть бизнес-логика = домен, то как минимум все доменные сущности должны быть в сторе домена и там же методы стора по изменению и управлению доменными сущностями, а в слое пользовательских сценариев уже должна располагаться логика приложения которая и должна вызываться на ваших страницах