Тут обсуждаемая статья как раз про то, что использовать формат Option Store - устаревший формат. И я с автором соглашусь.
Причем тут option? Это же просто синтаксический сахар, преобразуемый на этапе сборки в синтаксис composition. Я привел доказательство того, что методы в сторе как раз позиционируются как место для бизнес-логики самими авторами.
Наличие actions никак не зависит от синтаксиса, это одна из базовых возможностей pinia.
но все-таки лучше для этого использовать отдельные сервисы
Минус в том, что бизнес-логика разъезжается по разным файлам, и новый разработчик (или старый, после перерыва) легко может полезть в стор напрямую. Или наоборот забыть что то поменять в нем после общения с бэком
Десятки тысяч сущностей конечно хранить на клиенте не надо. В начале обсуждения такого условия не ставилось. А оно принципиальное.
А вот со списком товаров не совсем понятно. Если нет задачи отображать на экране несколько списков сразу - то я не понимаю, зачем вы пишите про дублирование списков внутри стора? Пусть будет один массив "отображаемые товары". И он бы изменялся с помощью вызова методов, внутри которых выполнялась загрузка данных. Или, если вам так важно, при вызове метода в сервисе, который загрузит данные а потом вызовет метод стора, и скопирует их в него.
Хм, да, что то об обратном потоке (управление) я совсем забыл) Как-нибудь сделать через встроенный "чат"?
А захват как экрана, так и конкретного окна вроде давно реализован всеми возможными приложениями видеоконференций. Наверное и в телемосте есть (сам не пользовался им, не знаю)
По сути, надо максимально похожим образом использовать его протокол. Раз есть видеопоток - гнать по нему именно видео с окна нужного приложения. Обратно можно тоже видео - пустой белый экран с курсором). В чат текстовые команды: MOUSE CLICK, MOUSE DOUBLE CLICK. Звучит как бред, зато вообще не подозрительно)
Помню, с их поддержкой переписывался на эту тему, сначала косили под дурачков (типа, снимите флажок "Заказы и другие уведомления", хотя я ясно писал, что мне нужны уведомления по заказам, а спам - не нужен), потом все же признали, что это невозможно.
Прошу прощения, это не на ваш комментарий ответ, случайно получилось
Я предлагаю использовать компонент, который будет запрашивать данные у сервиса и хранить их в себе.
Ну то есть у вас реально не было задач, когда одни и те же данные должны использоваться несколькими компонентами?
У стора S - это хранение данных, ну и плюсом идет каким-то образом их изменение.
Actions are the equivalent of methods in components. They can be defined with the actions property in defineStore() and they are perfect to define business logic:
А я считаю, что не нужно относиться к стору, как к тупому классу с полями и методами. Стор - это централизованное хранилище данных, используемых всей клиентской частью приложения. И не должны компоненты знать ничего о способе общения с сервером. Их дело - либо прочитать поле, либо вызвать метод этого хранилища. А уже внутри этого метода может быть как общая бизнес-логика (нельзя удалить товар из пустой корзины. нельзя удалить товар из корзины, если он там отсутствует. И т.п.), так и обновление всех или части данных при вызове этого метода
То есть, некий класс, который внутри себя использует стор и сервис взаимодействия с сервером (2 зависимости) - это хорошо?
А стор, который использует внутри себя сервис взаимодействия с сервером (1 зависимость) - это плохо?
А зачем логику частичного обновления данных стора предлагается вынести наружу - я понять не могу. Она завязана на структуры данных, хранящихся внутри этого стора, и ни на что более. S из solid не нарушается.
Хотя могу предположить, что у вас просто не было по настоящему сложных хранимых на клиентской стороне взаимозависимых структур данных, изменения части которых вызывают цепочки изменений в других данных. Или вы в таких случаях снова загружаете абсолютно все с сервера, даже если требуется поменять пару полей данных?
А зачем такие сложности, если можно просто пользоваться штатным механизмом и смотреть видеопотоком браузер или еще какое приложение, установленное на сервере в разрешенной локации
Ну, например, чтобы после вызова метода стора, он сам выполнил запрос к серверу, получил ответ, и обновил внутри себя связанные данные. А иначе, придется колхозить какие-нибудь шины событий или еще что.
Например. Есть форум. В нем есть обычная модалка для редактирования профиля пользователя. Поменял он аватарку. Сразу после изменения она должна обновиться везде, где отображается (во всех отображаемых сообщениях от него).
И кто вообще сказал, что стор должен обслуживать только один компонент? И что плохого в том, что он умный?
Вполне нормальный подход. Считаем стор единственным местом хранения данных. Все взаимодействие с бэком - скрыто внутри стора. Естественно, это не значит, что все нужно запихать в один файл, где объявлен этот самый стор.
Дефицит рабочих есть, только вот платить там все равно будут копейки. А работать "на себя" во-первых, не все смогут (искать клиентов и договариваться, это отдельный навык нужен), а во-вторых, нестабильный доход.
Не совсем понял, о чем Вы. Я же вроде ясно написал - "междомовую связь пока не обсуждаем". У меня в квартире вполне ловится вайфай с квартир на 2 этажа выше и ниже.
Когда человек рождается, он даже говорить не способен
Откуда такой вывод? Никто же еще не проверял. Не существует пока технологии пересадки мозга, а значит, это все ничем не подтвержденные домыслы.
Вроде как эксперименты с переливанием крови молодых старым показали, что резко улучшается состояние (на несколько дней)
Аналогичная ситуация с гормоно-заместительной терапией. Сравните старичков одного возраста на ГЗТ и без нее. Отличия кардинальные.
Причем тут option? Это же просто синтаксический сахар, преобразуемый на этапе сборки в синтаксис composition. Я привел доказательство того, что методы в сторе как раз позиционируются как место для бизнес-логики самими авторами.
Наличие actions никак не зависит от синтаксиса, это одна из базовых возможностей pinia.
Минус в том, что бизнес-логика разъезжается по разным файлам, и новый разработчик (или старый, после перерыва) легко может полезть в стор напрямую. Или наоборот забыть что то поменять в нем после общения с бэком
Десятки тысяч сущностей конечно хранить на клиенте не надо. В начале обсуждения такого условия не ставилось. А оно принципиальное.
А вот со списком товаров не совсем понятно. Если нет задачи отображать на экране несколько списков сразу - то я не понимаю, зачем вы пишите про дублирование списков внутри стора? Пусть будет один массив "отображаемые товары". И он бы изменялся с помощью вызова методов, внутри которых выполнялась загрузка данных. Или, если вам так важно, при вызове метода в сервисе, который загрузит данные а потом вызовет метод стора, и скопирует их в него.
Хм, да, что то об обратном потоке (управление) я совсем забыл) Как-нибудь сделать через встроенный "чат"?
А захват как экрана, так и конкретного окна вроде давно реализован всеми возможными приложениями видеоконференций. Наверное и в телемосте есть (сам не пользовался им, не знаю)
По сути, надо максимально похожим образом использовать его протокол. Раз есть видеопоток - гнать по нему именно видео с окна нужного приложения. Обратно можно тоже видео - пустой белый экран с курсором). В чат текстовые команды: MOUSE CLICK, MOUSE DOUBLE CLICK. Звучит как бред, зато вообще не подозрительно)
В таком случае стор вообще не нужен )
Грузите сразу из сервиса в компонент, раз кроме него, они нигде не требуются.
Помню, с их поддержкой переписывался на эту тему, сначала косили под дурачков (типа, снимите флажок "Заказы и другие уведомления", хотя я ясно писал, что мне нужны уведомления по заказам, а спам - не нужен), потом все же признали, что это невозможно.
Прошу прощения, это не на ваш комментарий ответ, случайно получилось
Паттерн Active Record тоже его формально нарушает, при этом применяется в каждом втором проекте для веба
Ну то есть у вас реально не было задач, когда одни и те же данные должны использоваться несколькими компонентами?
А я считаю, что не нужно относиться к стору, как к тупому классу с полями и методами. Стор - это централизованное хранилище данных, используемых всей клиентской частью приложения. И не должны компоненты знать ничего о способе общения с сервером. Их дело - либо прочитать поле, либо вызвать метод этого хранилища. А уже внутри этого метода может быть как общая бизнес-логика (нельзя удалить товар из пустой корзины. нельзя удалить товар из корзины, если он там отсутствует. И т.п.), так и обновление всех или части данных при вызове этого метода
Зачем? Фильтруйте и сортируйте внутри компонента (computed или вызов метода), а данные должны лежать в сторе, и не меняться
А авторы pinia в своей документации утверждают, что можно и нужно. И я им верю больше.
То есть, некий класс, который внутри себя использует стор и сервис взаимодействия с сервером (2 зависимости) - это хорошо?
А стор, который использует внутри себя сервис взаимодействия с сервером (1 зависимость) - это плохо?
А зачем логику частичного обновления данных стора предлагается вынести наружу - я понять не могу. Она завязана на структуры данных, хранящихся внутри этого стора, и ни на что более. S из solid не нарушается.
Хотя могу предположить, что у вас просто не было по настоящему сложных хранимых на клиентской стороне взаимозависимых структур данных, изменения части которых вызывают цепочки изменений в других данных. Или вы в таких случаях снова загружаете абсолютно все с сервера, даже если требуется поменять пару полей данных?
Мы с приятелем в НИИ
Разработали ИИ
(с)
А зачем такие сложности, если можно просто пользоваться штатным механизмом и смотреть видеопотоком браузер или еще какое приложение, установленное на сервере в разрешенной локации
Ну, например, чтобы после вызова метода стора, он сам выполнил запрос к серверу, получил ответ, и обновил внутри себя связанные данные. А иначе, придется колхозить какие-нибудь шины событий или еще что.
Например. Есть форум. В нем есть обычная модалка для редактирования профиля пользователя. Поменял он аватарку. Сразу после изменения она должна обновиться везде, где отображается (во всех отображаемых сообщениях от него).
И кто вообще сказал, что стор должен обслуживать только один компонент? И что плохого в том, что он умный?
Вполне нормальный подход. Считаем стор единственным местом хранения данных. Все взаимодействие с бэком - скрыто внутри стора. Естественно, это не значит, что все нужно запихать в один файл, где объявлен этот самый стор.
А не дешевле ли? Делаете больше за те же деньги
В Северной Корее говорят до сих пор есть аналогичный запрет )))
Дефицит рабочих есть, только вот платить там все равно будут копейки. А работать "на себя" во-первых, не все смогут (искать клиентов и договариваться, это отдельный навык нужен), а во-вторых, нестабильный доход.
Не совсем понял, о чем Вы. Я же вроде ясно написал - "междомовую связь пока не обсуждаем". У меня в квартире вполне ловится вайфай с квартир на 2 этажа выше и ниже.