Как я понял в приоритете для связи у библиотеки веб-сокет, если зта технология недоступна sse. Но стоит ли держать двустороннее соединение открытым для получения пушей с сервера?
А если использовать sse из библиотеки возможно легче реализовать подобный метод чем тащить всю библиотеку? )
В данном контексте я бы вообще не привязывался к vue или подобной другой библиотеке или фреймворку.
signalR с этим не совсем знаком, но судя по описаеию для связи там используются WebSockets, Server-sent events, Forever Frames, Long polling.
Например основная разница между WebSockets и Server-sent events это направленность потоков. В последнем случае это только сервер —> клиент. Как я понял, это то, что вам нужно. Возможно используя signalR там также будет использоваться sse.
Здесь уже вам решать, использовать библиотеку, где возможно реализованны нужные для вас методы или городить собственный огород на нативной реализации. Наверное нужно взвесить плюсы и минусы обеих реализаций и принять непростое решение )
Farkl, можно если данные получаем в app.vue и нужно помнить, что реактивность нужно прикрутить, ну например провайдить тот же реактивный const company = reactive(null)
Важно, чтобы app.vue был корневой, а остальные компоненты в которые провайдится, дочерними. При этом нужно понимать, что дочерние компоненты становятся зависимыми от компонента, который провайдит.
import { reactive } from 'vue'
export const useCompany = () => {
const company = reactive(null)
return company
};
Ну и подрубать этот хук в нужных компонетах. А чтобы совсем на стор похоже было, в хук можно добавить методы добавления, удаления данных, можно сделать вычисляемые computed методы (геттеры) только нужно все это ретурнить чтобы было доступно.
