Общий родитель есть всегда - это рут. Чтобы его не загрязнять, можно то что провайдится, затащить внешним файлом js.
Про отслеживание событий я написал ниже.
А так вы затащили в проект ещё одну зависимость, которую, во-первых, нужно понимать всем, кто работает в проекте, а во-вторых - поддерживать. Вместо того, чтобы использовать сам vue и его парадигмы, которые понятны всем и доступны из коробки.
ИМХО, это пятая нога - вы облегчили одно и усложнили другое.
Но, вообще, чтобы понять что решали, было бы очень неплохо увидеть реальную задачу.
Если договориться о стандарте именования, например, сделать события вида [НазваниеКомпонента]_[Событие]_[ID], где ID - это идентификатор экземпляра компонента, если компонентов такого вида может быть несколько.
После такого соглашения понимать что за компонент райзнул событие очень просто, как и найти подписчиков на него. Можно для дебага перехватывать все события и кидать в консоль и тд.
Я бы не сказал, что это неочевидней provide/inject, а самое главное - никаких внешних зависимостей и парадигм тащить не надо - работает из коробки.
Плюсов масса - если компоненты каким-то образом подписаны на события друг-друга, например когда есть модальный лоадер, а другие компоненты при асинхронке кидают события типа Loader_On/Off, то, достаточно просто подключить компонент лоадера и любой другой компонент, вообще ничего не зная про связь - и они подружатся сами. А если вы не подключили лоадер - никакой ошибки не будет, тк событие будет уходить, но подписчиков у него нет.
Я не очень понял суть задачи — надо расшарить какие-то данные/события между какими-то иерархически несвязанными/связанными компонентами?
Если да, то максимально корректный в парадигме Vue — это provide/inject.
А если с этим не заморачиваться, то (имхо) самый удобный — event-bus на руте (либо внешний через mixin/globals). В нем можно как райзить события-данные, так и события-логику, получают их все подписанные на нужные события компоненты, что очень удобно. Расплата за это только одна — отследить типы событий и где они порождаются и где ловятся — сложно. Но, если именование событий стандартизировать, то ищется в проекте элементарно поиском по названию события.
Не увидел event-bus в статье, кстати — но может быть потому, что неверно задачу понял. Поясните, если не трудно, можно просто простым примером задачи.
Блог, да, но статьи в ленте появляются отдельными, и далеко не все зайдут почитать что-то про вас, кроме того, ваши статьи кочуют между блогами — сегодня, например, это блог TimeWebCloud.
Кстати, сигнал «стоп» на велосипеде — актуальней некуда, говорю вам как человек с опытом катания под 10 лет. И у меня стоит такая фара. Стоп распознается автоматически акселем.
А че не на ПЗУ-шке? Там как раз 8 выводов, анимацию разделить на чанки, генератор гоняет по кругу только один чанк, чанки — это динамические действия типа «поворот направо» или «стоп», в каждом чанке каждый байт — состояние полоски диодов, на ПЗУ на вывод битов прямо прилепить диоды — выходы там мощные достаточно, размер чанка фиксированный и кратен степени 2 — чтобы выбирать было проще.
Но вообще, в каждой такой статье я бы вверху давал дисклеймер — «не надо так делать в 2022», или «я так делаю, потому что хочу и могу, а не потому что это правильно» :)
Ибо данная штука делается на attiny за 70рэ (или на китайском за 15рэ) и 8 адресных диодах WSxxxx, при этом плюсом идет RGB, любые переливы и анимация и у вас еще останется 4 свободных линии из 6 (1-лента диодов, 1-ацп на кнопки выбора режима), по которым можно подключить аксель, например. И все это уложится в платку 10x10мм и жрать будет куда меньше за счет ШИМ.
Вот про решетку — отдельная тема — из чего ее делать и как, 3D врядли подойдет, так как при печати и такой толщине ее поведет. Фрезерование только, ИМХО.
Пример — дисплей 8x40 — вполне достаточно для проекта = 320 диодов, первый лот на али, который нашел: sk6805 300шт = 24$, 100шт = 9.5$
Мало того, они в наличии в JLCPCB и вам их еще и напаяют за копейки и возьмут со своих стоков.
Про SK6805 не знал, уже развел на EASYEDA матрицу, закажу, пожалуй ради интереса, единственный вопрос — как делать решетку с минимальной толщиной для него.
Когда покупали - таких не было. Сейчас есть, но про них ничего сказать не могу - ибо проблему закрыли и забыли. Но, если бы сейчас надо было - наверное взял бы на адресных и прикрутил к ним ESP от WEMOS - wifi будет, да и с Ethernet-shield-ом есть.
Есть таблички и с софтом на PC и с просто USB подключением - это просто первое попавшееся.
Протокол там примитивный, у нас ушло порядка получаса на все это. Как потом выяснилось - можно было списаться с китайцами и попросить спеки) Таблички используются в опен-спейсе для переговорок. Выводить хоть видео можно, правда частота обмена не высокая. Мы выводим и таймер и бешущую строку с тем кто занимает, и сколько до конца.
Качество есть всякое, мы покупали их по 40$ - качество отличнейшее, сверху на панель светодиодов наложена решетка, затем тёмная пластина - не видно ни диодов, ни засветов между ними, лишь чёткая яркая картинка, мы выбрали оранжевое свечение - видно как вблизи, так и издалека. Не раздражает.
Размер наших табличек 300х80мм - абсолютно не большие по размеру. Выбора размеров тоже куча.
Софт? Мы написали скрипт на питоне за час, который выводил таймер и строку. У нас была ещё проблема, что надо централизовано несколькими управлять, у вас такого нет - писать там толком нечего.
Хотите автономный вариант? Без проблем, как думаете разобрали ли мы хотя-бы одну штуку?) Пока выбирали - разобрали массу. Есть на адресных диодах (ws28xx), они покрупнее и RGB - там с выводом и ATTINY справится, паять ровно 1 вывод и ещё 2 - это земля и питание, все либы лежат в открытом доступе. Одного цвета на обычных диодах с чарлиплексингом или сдвиговыми регистрами - тоже не сказать что какая-то сильная магия. Но уже есть корпус нормальный и экран. На адресных и тиньке сделать прошивку с эмуляции USB на клоне дигиспаркрвской платки и VUSB - ну не знаю... часов 5.
Все уже давно сделано - на ali ищется как bluetooth led screen, стоимость в зависимости от размера, разрешения и цвета (есть и RGB) от 20 до 80$, первый попавшийся пример
Но на домашнем VDS приложений обычно совсем не много и они гомогенные — те им вполне достаточно того, что стоит в системе.
Если же пользоваться 3rd-party решениями — типа owncloud и тд — вот тогда да — есть смысл точно, чтобы не маяться с зависимостями чужими.
Кстати про миграцию — может потому что я больше программист, чем админ — я никогда не настраиваю сервак вручную — у меня есть bash-скрипт, в котором я прописал все нужные сервисы и их конфигурации. У меня оно на Debian-е, и для того, чтобы развернуть мне сервак на новом месте, мне нужна голая система, баш и мой скрипт — я его запускаю он сам ставит пакеты, сам конфиугрирует их и сервисы, прописывает что нужно в iptables/config-ах. Да, конечно, если что-то сильно изменили — конфиг нужно будет подправить, но я стараюсь писать его так, чтобы он как можно меньше использовал спец. пакетов, а старался использовать стандартные утилиты и на моей памяти было всего один раз, когда был какой-то конфликт, связанный с обновленным пакетом. По мне — так тоже выход, причем без оверхэда. И при этом не нужно заморачиваться с конфигурацией внешней и внутренней сети докера, а самое главное — оно будет работать на vds с гораздо меньшими требованиями по памяти и цпу, что очень сильно влияет на его цену.
Я правильно понимаю, что watch с immdiate и deep куда универсальней watchEffect?
Хотя-бы потому, что не нужна пляска с бубном с развертыванием отслежиемого объекта, если нужно следить за изменением внутри объекта (как в примере массив), мало того, используя $watch его можно точно также остановить через unwatch, плюсом можно получить предыдущее состояние объетка.
По-этому мне все еще не понятно зачем нужен watchEffect…
Документация там отличная, ибо платка использована в тысячах проектов. Что до звука - не HiFi, но и у вас там не оперный зал - играет оно вполне на уровне.
Но самое главное - что мешало вообще играть не mp3, а wav? Тогда вообще без модуля бы обошлись. А карточку и плеер тянет даже ATTINY-25 (http://elm-chan.org/works/sd8p/report.html) и да, будет читать прямо с FAT.
Опять-же что мешало сделать на STM программный MP3-плеер?
Из документации по VUE.
VUE Composition API появилась только во VUE3.
Общий родитель есть всегда - это рут. Чтобы его не загрязнять, можно то что провайдится, затащить внешним файлом js.
Про отслеживание событий я написал ниже.
А так вы затащили в проект ещё одну зависимость, которую, во-первых, нужно понимать всем, кто работает в проекте, а во-вторых - поддерживать. Вместо того, чтобы использовать сам vue и его парадигмы, которые понятны всем и доступны из коробки.
ИМХО, это пятая нога - вы облегчили одно и усложнили другое.
Но, вообще, чтобы понять что решали, было бы очень неплохо увидеть реальную задачу.
Чем event-bus меганеочевиден?
Если договориться о стандарте именования, например, сделать события вида [НазваниеКомпонента]_[Событие]_[ID], где ID - это идентификатор экземпляра компонента, если компонентов такого вида может быть несколько.
После такого соглашения понимать что за компонент райзнул событие очень просто, как и найти подписчиков на него. Можно для дебага перехватывать все события и кидать в консоль и тд.
Я бы не сказал, что это неочевидней provide/inject, а самое главное - никаких внешних зависимостей и парадигм тащить не надо - работает из коробки.
Плюсов масса - если компоненты каким-то образом подписаны на события друг-друга, например когда есть модальный лоадер, а другие компоненты при асинхронке кидают события типа Loader_On/Off, то, достаточно просто подключить компонент лоадера и любой другой компонент, вообще ничего не зная про связь - и они подружатся сами. А если вы не подключили лоадер - никакой ошибки не будет, тк событие будет уходить, но подписчиков у него нет.
Если да, то максимально корректный в парадигме Vue — это provide/inject.
А если с этим не заморачиваться, то (имхо) самый удобный — event-bus на руте (либо внешний через mixin/globals). В нем можно как райзить события-данные, так и события-логику, получают их все подписанные на нужные события компоненты, что очень удобно. Расплата за это только одна — отследить типы событий и где они порождаются и где ловятся — сложно. Но, если именование событий стандартизировать, то ищется в проекте элементарно поиском по названию события.
Не увидел event-bus в статье, кстати — но может быть потому, что неверно задачу понял. Поясните, если не трудно, можно просто простым примером задачи.
Но это был просто совет и ничего более.
Но вообще, в каждой такой статье я бы вверху давал дисклеймер — «не надо так делать в 2022», или «я так делаю, потому что хочу и могу, а не потому что это правильно» :)
Ибо данная штука делается на attiny за 70рэ (или на китайском за 15рэ) и 8 адресных диодах WSxxxx, при этом плюсом идет RGB, любые переливы и анимация и у вас еще останется 4 свободных линии из 6 (1-лента диодов, 1-ацп на кнопки выбора режима), по которым можно подключить аксель, например. И все это уложится в платку 10x10мм и жрать будет куда меньше за счет ШИМ.
Пример — дисплей 8x40 — вполне достаточно для проекта = 320 диодов, первый лот на али, который нашел: sk6805 300шт = 24$, 100шт = 9.5$
Мало того, они в наличии в JLCPCB и вам их еще и напаяют за копейки и возьмут со своих стоков.
Про SK6805 не знал, уже развел на EASYEDA матрицу, закажу, пожалуй ради интереса, единственный вопрос — как делать решетку с минимальной толщиной для него.
Показать не могу, тк это внутренности фирмы)
Но USB там нет, BT же. В каждой переговорке есть комп с BT, который соеденяется с табличкой, через него, собственно, данные и отдаются.
Есть WS28xxC mini 3.5mm - это самое маленькое из адресных что знаю.
Когда покупали - таких не было. Сейчас есть, но про них ничего сказать не могу - ибо проблему закрыли и забыли. Но, если бы сейчас надо было - наверное взял бы на адресных и прикрутил к ним ESP от WEMOS - wifi будет, да и с Ethernet-shield-ом есть.
Есть таблички и с софтом на PC и с просто USB подключением - это просто первое попавшееся.
Протокол там примитивный, у нас ушло порядка получаса на все это. Как потом выяснилось - можно было списаться с китайцами и попросить спеки) Таблички используются в опен-спейсе для переговорок. Выводить хоть видео можно, правда частота обмена не высокая. Мы выводим и таймер и бешущую строку с тем кто занимает, и сколько до конца.
Качество есть всякое, мы покупали их по 40$ - качество отличнейшее, сверху на панель светодиодов наложена решетка, затем тёмная пластина - не видно ни диодов, ни засветов между ними, лишь чёткая яркая картинка, мы выбрали оранжевое свечение - видно как вблизи, так и издалека. Не раздражает.
Размер наших табличек 300х80мм - абсолютно не большие по размеру. Выбора размеров тоже куча.
Софт? Мы написали скрипт на питоне за час, который выводил таймер и строку. У нас была ещё проблема, что надо централизовано несколькими управлять, у вас такого нет - писать там толком нечего.
Хотите автономный вариант? Без проблем, как думаете разобрали ли мы хотя-бы одну штуку?) Пока выбирали - разобрали массу. Есть на адресных диодах (ws28xx), они покрупнее и RGB - там с выводом и ATTINY справится, паять ровно 1 вывод и ещё 2 - это земля и питание, все либы лежат в открытом доступе. Одного цвета на обычных диодах с чарлиплексингом или сдвиговыми регистрами - тоже не сказать что какая-то сильная магия. Но уже есть корпус нормальный и экран. На адресных и тиньке сделать прошивку с эмуляции USB на клоне дигиспаркрвской платки и VUSB - ну не знаю... часов 5.
Все ИМХО:
Вы со следствием боритесь, а не с причиной.
Все уже давно сделано - на ali ищется как bluetooth led screen, стоимость в зависимости от размера, разрешения и цвета (есть и RGB) от 20 до 80$, первый попавшийся пример
Но на домашнем VDS приложений обычно совсем не много и они гомогенные — те им вполне достаточно того, что стоит в системе.
Если же пользоваться 3rd-party решениями — типа owncloud и тд — вот тогда да — есть смысл точно, чтобы не маяться с зависимостями чужими.
Кстати про миграцию — может потому что я больше программист, чем админ — я никогда не настраиваю сервак вручную — у меня есть bash-скрипт, в котором я прописал все нужные сервисы и их конфигурации. У меня оно на Debian-е, и для того, чтобы развернуть мне сервак на новом месте, мне нужна голая система, баш и мой скрипт — я его запускаю он сам ставит пакеты, сам конфиугрирует их и сервисы, прописывает что нужно в iptables/config-ах. Да, конечно, если что-то сильно изменили — конфиг нужно будет подправить, но я стараюсь писать его так, чтобы он как можно меньше использовал спец. пакетов, а старался использовать стандартные утилиты и на моей памяти было всего один раз, когда был какой-то конфликт, связанный с обновленным пакетом. По мне — так тоже выход, причем без оверхэда. И при этом не нужно заморачиваться с конфигурацией внешней и внутренней сети докера, а самое главное — оно будет работать на vds с гораздо меньшими требованиями по памяти и цпу, что очень сильно влияет на его цену.
Вот, например, стандартный VDS стандартного IT-шика: там, обычно nginx/apache/lhttpd + python/php/node + OpenVPN/WG и все — смысл там ставить докер?
Разве что если на нем хостить публичный сайт, чтобы если root-а получат, не вылезли из гостевой оси… ну такое.
Ошибаюсь?
Ростелеком и ВПН и ГОСТ - прямо все звезды сошлись - точно будет безопасно - вопрос - для кого?
Ну вот разве что события, опять-же этого можно добиться в watch через nextTick нет?
Хотя-бы потому, что не нужна пляска с бубном с развертыванием отслежиемого объекта, если нужно следить за изменением внутри объекта (как в примере массив), мало того, используя $watch его можно точно также остановить через unwatch, плюсом можно получить предыдущее состояние объетка.
По-этому мне все еще не понятно зачем нужен watchEffect…
Документация там отличная, ибо платка использована в тысячах проектов. Что до звука - не HiFi, но и у вас там не оперный зал - играет оно вполне на уровне.
Но самое главное - что мешало вообще играть не mp3, а wav? Тогда вообще без модуля бы обошлись. А карточку и плеер тянет даже ATTINY-25 (http://elm-chan.org/works/sd8p/report.html) и да, будет читать прямо с FAT.
Опять-же что мешало сделать на STM программный MP3-плеер?