Руслан: да, именно так же, не более, но меня уже напрягает с точки зрения эстетики) меняй, я теперь подкладываю микрофибру на клавиатуру когда закрываю, подумываю вторую микрофибру купить
В студии VS Code очень хороший плагин для go, чекает ошибки, форматирует, билдит и т.д. Для vue использую vetur и всякие автокомплиты/автоклоусы для верстки и далее уже по набору tslint/jslint sass/css...
ezpy:
1. у меня открыто 2 студии (vs code): первая для go, вторая для фронта. go перезапускаю вручную (потому что на каждое сохранение настроен ребилд и вывод ошибок, форматирование, думаю в настройках проекта/студии можно настроить перезапуск приложения, видимо можно и через галп, но надо смотреть чтобы время ребилда-перезапуска не напрягало)
Посмотри как сделано в nuxt.js (https://github.com/nuxt) - это оболочка над vuejs (генератор кода vue + грамотно настроено окружение), там при сохранении файла приложение само ребилдится.
2. я всё-таки за разделение бэкэнда апи и бэкэнда для статики (nodejs), завязывать go на хостинг статических файлов и роутинга - прошедший путь, он не гибок (но если только это не в качестве оптимизации под какое-то конкретное устройство raspberry pi например, где всё приложение монолит на го и запускается одной командой).
Мой совет-максимально изолировать API и Vuejs тогда будет проще масштабировать на кластере: vue на ноде можно будет поднять сразу несколько инстансов (оч понадобится если придется делать серверный рендеринг), апи поднять тоже несколько для распределения нагрузки, перед этими инстансами стоит 2 контейнера: 1 haproxy и балансирует на разные инстансы API, 2 haproxy и балансирует на разные ноды vuejs. Получится максимально гибкая конфигурация, повторюсь для поддержки зоопарка docker. Это всё для продакшена. Для девелопа достаточно отдельно запущенного go приложения и nodejs приложения. Пока не представляю как при ребилде go приложения, делать что-то "умное" c vuejs, только если авторефреш страницы повесить.
3. Я использую еще rxjs, в сценарии работы с веб-сокетами очень удобно, создали отдельный обработчик веб-сокет пушей с сервера и подписываемся на него с разных компонентов и не паримся.
По поводу установки - да нужно npm install и потом ребилд, но это редкие операции поэтому заносить в логику пересборки не нужно. При разворачивании в докере он сам устанавливает если находит разницу в package.json (то есть он просто пересобирает образ делая npm install)
Multigame: замыкание же, в чем проблема? на примере echo
app.GET("/test", func(ctx echo.Context) error { // "подписка" в main пакете
// handlerFromAnotherPackage это хэндлер из другого пакета, там просто добавить параметр канала, main_ch инициализированный в main и который передается в хэндлер вторым параметром,
return handlerFromAnotherPackage(ctx, main_ch)
})
n3uro: 2-3 дня. После первой замены где-то через месяц более-менее активного использования стало опять отслаиваться, заменили второй раз уже за 1 день. В сервисе дают гарантию 3 мес - приходится теперь каждые 3 месяца ходить менять. Говорят на 12 дюймовых тоже стали приходить с такими проблемами. Последние версии Pro ещё случаев не было.
ikerya: тогда сделать обертку над элементом, к ней повесить mousedown, и подписаться на событие начав захват
wrapperElement.addEventListener( 'click', function ( ev ) {
ev.stopImmediatePropagation();
ev.stopPropagation();
}
},true);
silverjoe: да, на твоей модели всё ок должно быть, эта проблема всех ретин (там покрытие такое фиолетовое), оно присутствует на 12ках, на прошках и в любой модели оно со временем по причине соприкосновения с клавой начинает слезать (многие не парятся и ничего не делают, можно заменить по гарантии, можно его смыть и будет обычное стекло-тогда ретина нафиг не нужна)
прошка 15 года - 13 дюймов: мучения с дисплеем ретина - облазит антиблик на местах соприкосновения с клавой, уже 2 раза меняли по гарантии, видимо будут 3й и так далее
хотя оно того стоит
Александр Марченко: неполноценная гидрация у юниверсал, только пока результаты запросов может, стор не умеет, мы уже писали в ишьюс разрабам по поводу неправильной схемы взятой от вью (https://vuejs.org/images/hn-architecture.png) , они признали что это так.
надо ещё написать что сообщения в ws называются фреймами и об их ограничениях, потому что посылая сообщение можно получить 1 и более фреймов и это всплывает на принимающей стороне, особенно в стандартном пакете go net/http
vetsmen: тогда ещё проще: хранишь ключ-значение. Ключ-логин пользователя, значение-объект хранящий флаг авторизации и кол-во сокетных соединений. При дисконнекте: уменьшаешь кол-во на 1, если кол-во сокетных соединений 0, то убираешь пользователя из словаря, если нет, то выставляешь флаг в актуальное значение. При каждой операции проверяешь словарь и флаг авторизации для пользователя.
vetsmen: тебе нужно хранить словарь, где ключ - это логин, а значения - это список указателей на открытые сокеты, как только один из сокетов инициирует логаут, ты пробегаешь по списку и логаутишь все соединения.