Если я правильно помню, в самом начале вообще все было бесплатно, а ограничений не было по доставке совсем. Можно было и батарейки пальчиковые на доставку ставить?
С помощью контекста выясняем что за история сейчас будет показываться (св-во name) ну и формируем нужный нам глобальный контекст:
if (context.name === 'Story with special state') {
Vue.use({
install: (vueObj) => {
vueObj.prototype.$globalProp = ...;
}
});
Решение далеко от идеала, конечно, потому что аффектит все инстансы Vue, создаваемые после такого инджекта. По-хорошему бы восстанавливать исходный стэйт после отработки истории — наверняка и такое есть, будем копать дальше.
Таким образом в каждой истории перед маунтом мы будем подменять сущности на нужные моки и истории будут изолированы.
Вопрос мой как раз про сей момент, на самом деле. Как там запросы мокать и компонент с минимумом логики оформлять (без походов в сеть) — тут все понятно, не впервой. Вот как кастомный контекст подсунуть во Vue компонент, в котором оный как раз представлен в виде глобальной переменной — это не получается пока осилить. vue-test-utils позволяет в mount передавать mocks и при написании юнит тестов мы эту проблему решаем ровно таким образом. Вот в случае со storybook/vue не припоминаете что-нибудь подобное?
все-таки завел я эту машинерию — действительно пришлось сильно с webpack повозиться.
Вот Вы упомянули vue-test-utils и jest — подозреваю как-то они использовались, чтобы мокать глобальные параметры/запросы в stories. Не поделитесь опытом как это делается? А то storybook/vue lack of documentation и сколько ни рыл просторы инета по этой казалось бы основнополагающей теме — безрезультатно( Если есть пример кода где манкипатчится какой-нибудь глобальный Vue параметр для конкретной истории (чтобы это не затрагивало остальные) — вот был бы прям реально благодарен)
Максим, а не поделитесь примером стека, на котором у вас все это работает? Начиная с версии ноды думаю даже. Просто предпринимаю 2-ю попытку привнести все это в наш Vue JS проект и терплю фиаско — какие-то странные проблемы возникают — банально вот сейчас не работает автоматический резолвинг расширений в импортах при сборке storybook — ну казалось бы…
о, интересно — спасибо за наводку — погляжу на досуге. Но опять же дело было не только в объеме или там вложенности папок — это все не так страшно. А вот очень много маленьких файлов, кол-во которых от общего, которые надо засинкать, 80% — уверен повергнет любой бэкап софт в уныние. Не знаю как там AE этот себя ведет, но в Я.Д клиенте не поймешь толком даже прогресс чего там засинкалось, а что нет — шуршит себе чего-то, траффик генерит, а когда там процесс сойдется можно только догадываться. Отсюда и весь мой экскурс — с rsync как-то все более подконтрольно и понятно в этом плане: копирование идет последовательно по папкам с датами и можно четко видеть где мы сейчас находимся + exclude на папки с ресурсами, которые заливаем большими tar'ами. В общем, я практически уверен, что ни один удобный софт такие кейсы не покрывает — уж слишком много специфики.
Распаковывать, думаю, нет. Т.е. процедура восстановления из бэкапа подразумевает, что я распакую это сам. Благо, восстанавливаться из бэкапов в реальной жизни приходится не так часто — я в своей практике наступал на это пару раз только, наверно, — отсюда и секрет успеха компании Acronis) iPhoto эти папки конечно же нужны — не зря ж оно их лопатит. Посему я планировал актуальность их поддерживать и как вы правильно заметили заливать каждый раз полный архив поверх. Про то, что tar из коробки умеет дифференциальные бэкапы делать — не знал — спасибо за наводку — это действительно может существенно облегчить доливки — поизучаю вопрос.
ну что ж снимаю шляпу: рабочий хак действительно. Но только вот, боюсь, не будет это нормально работать на моих объемах: я для пробы залинковал сейчас маленькую медиатеку на 17 Гб всего и Яндекс.Диск ушел долго и упорно синкать — внешний хард мне сейчас безболезненно не оторвать, соответственно. Напоминаю, помимо полезного объема там есть еще медиа-трэш в медиатеке, который iPhoto сам создает в процессе своей работы. И это добро, подозреваю, постоянно плодится/распухает/меняется. Это много-много маленьких файликов — на синхронизацию этого дела может уйти масса времени. Я в своих испытаниях это все засунул в один большой архив и быстренько залил в облако. Держать внешний хард подключенным к компу месяц пока там все засинкает Я.Д — не вариант. С другой стороны, проделав это раз, наверно, будет он все быстро синкать — возможно. Надо проверять — в любом случае спс за идею)
вот щас не понял — что это дает-то? Еще раз проблема: медиатека на внешнем харде. Не лежит она в папке Яндекс диска вообще. Мне ее надо залить в облако.
ну норм чего, я пытался просто найти что-нибудь именно на iPhoto заточенное из приложений резервного копирования — не нашел и пошел сам педалить — что решение идеальное я даже не претендую ни разу: не секьюрно, достаточно много ручных приседаний — не прям все из коробки. Но у меня не так часто возникает идея подоливать фотки в облако — так что для меня норм работает.
работает-работает, rclone этот я так понимаю много на себя берет в плане автоматизации — отсюда и проблемы. Здесь же просто WebDav шара в контексте своего аккаунта. Чем я там лью rsync или просто команды cp/mv дергаю они, по сути, даже знать не могут.
Да пожалуйста, но что это отменяет?) Я сильно не параною по поводу того, что фотки на внешнем облаке лежат. Мне главное бэкап и возможность доливки в него с минимальными издержками. Предложенный вами вариант подразумевает заливку каждый раз полного архива фоток я так понимаю. В моем случае это более 800 Гб и это боль.
Отличная статья — спасибо! Выносило мозг — не мог понять в чем задумка в protobuf в случае когда не знаешь какое сообщение тебе свалится на вход и как парсить. Теперь все встало на свои места.
Мне все-таки непонятно с примером
{}+[]+{}+[1]. Ну т.е. объяснение, что первые скобки игнорируются как пустой блок кода, вроде бы, работает:Но:
Вот что тут произошло? С чего вдруг первые скобки стали рассматриваться не как пустой блок кода, а как объект?
С помощью контекста выясняем что за история сейчас будет показываться (св-во name) ну и формируем нужный нам глобальный контекст:
Решение далеко от идеала, конечно, потому что аффектит все инстансы Vue, создаваемые после такого инджекта. По-хорошему бы восстанавливать исходный стэйт после отработки истории — наверняка и такое есть, будем копать дальше.
В любом случае спасибо за ликбез)
Вопрос мой как раз про сей момент, на самом деле. Как там запросы мокать и компонент с минимумом логики оформлять (без походов в сеть) — тут все понятно, не впервой. Вот как кастомный контекст подсунуть во Vue компонент, в котором оный как раз представлен в виде глобальной переменной — это не получается пока осилить. vue-test-utils позволяет в mount передавать mocks и при написании юнит тестов мы эту проблему решаем ровно таким образом. Вот в случае со storybook/vue не припоминаете что-нибудь подобное?
Вот Вы упомянули vue-test-utils и jest — подозреваю как-то они использовались, чтобы мокать глобальные параметры/запросы в stories. Не поделитесь опытом как это делается? А то storybook/vue lack of documentation и сколько ни рыл просторы инета по этой казалось бы основнополагающей теме — безрезультатно( Если есть пример кода где манкипатчится какой-нибудь глобальный Vue параметр для конкретной истории (чтобы это не затрагивало остальные) — вот был бы прям реально благодарен)
Распаковывать, думаю, нет. Т.е. процедура восстановления из бэкапа подразумевает, что я распакую это сам. Благо, восстанавливаться из бэкапов в реальной жизни приходится не так часто — я в своей практике наступал на это пару раз только, наверно, — отсюда и секрет успеха компании Acronis) iPhoto эти папки конечно же нужны — не зря ж оно их лопатит. Посему я планировал актуальность их поддерживать и как вы правильно заметили заливать каждый раз полный архив поверх. Про то, что tar из коробки умеет дифференциальные бэкапы делать — не знал — спасибо за наводку — это действительно может существенно облегчить доливки — поизучаю вопрос.