История вопроса

В этой статье пойдёт речь о том, как я пришёл к тому, чтобы взяться писать плагин, создающий на лету vue компоненты из самописных svg иконок во время сборки проекта, о том, как я это делал, и о том, что в итоге получилось.

Мне уже давно и прочно нравится мир Vue. Особенно завораживает скорость, с которой в нём рождаются новые возможности писать код более лёгким и понятным. Недавно появились Composition API, VueUse, Vite… По ходу освоения этих новых инструментов я нашёл шаблон Vitesse, буквально насыщенный удобными средствами — и для управления макетами (layout), и для маршрутизации, и для локализации и ещё для много чего… Возможно, есть смысл написать отдельный обзор этого арсенала по русски (чего в Интернете пока ещё нет). Но сейчас речь не об этом.

В этой небольшой статье мы с вами напишем свое простое приложение по типу "заказа еды". Само приложение если что будет статичным и здесь главный упор будет сделан на использование компонентов Vuetify и рассмотрение того как именно они работают. Также добавлю что здесь мы не будем рассматривать отдельную библиотеку Bootstrap Vue которую использует Vuetify чтобы строить гриды.

В 2018 решил освоить Vue.js, так, для общего развития, а как известно, лучший способ освоить язык/фреймворк/etc — начать писать. В голову пришла довольно простая идея, которая со временем выросла в довольно большой проект — онлайн сервис «Места», позволяющий создавать свои коллекции мест на карте, геометок, с подробной информацией о них. Собирать их в альбомы, сортировать в дереве папок, просматривать, редактировать, обмениваться с другими, открывать для просмотра другим пользователям сервиса. Привязывать к местам фотоальбомы, экспортировать свои библиотеки в файлы JSON и GPX (для навигаторов, например), импортировать в свои библиотеки места других людей.

Идея была проста. Есть множество средств создания фотоальбомов, музыкальных плейлистов — с описаниями, возможностью сортировки, ссылками, преферансом и барышнями. А похожей полноценной картографической реализации толком нет. По крайней мере, я не нашёл.

Представьте, что вы пошли с другом в поход. Каждый у себя в навигаторе смартфона отмечал какие-то интересные места — удобные стоянки, опасные пороги, прохождение которых описывал. Потом вернулись домой, и каждый остался при своих. Сервис позволяет собрать их вместе, слив оба набора в один, отсортировать, разложить по папкам, отредактировать описания в удобном интерфейсе на компе, добавить фотографии, ссылки, сделать при желании видимыми другим пользователям сервиса, экспортировать потом, в конце концов, для использования в навигаторах и т. д.

Проект свободный (https://github.com/assador/places, сам действующий сервис пока здесь: http://places.scrofa-tridens.ru). Сейчас в планах помимо API Яндекс.Карт, которые отвечают, собственно, за карту, подключить и другие — OSM, 2ГИС и пр. Хочу добавить возможность добавлять к местам не только фото-, но и видео-, и аудиоальбомы. Развивать структуру прав и ролей пользователей, их связь друг с другом на сервисе, расшаривать библиотеки в соцсети и пр. Короче, для меня штука интересная.

Примерно год назад фронтенд нашего проекта, в качестве фреймворка для которого используется Vue.js 2, дошел до состояния, хорошо описываемого словами "проще сжечь".

К тому времени наш нетипизированный корабль уже трещал по всем швам, и решено было убить сразу нескольких зайцев одним выстрелом: полностью перевести проект на TypeScript, внедрить Vue Composition API и решить проблемы валидации сложных форм.

А проблемы были. Vuelidate - отличная библиотека с массой готовых валидаторов и остается таковой до тех пор, пока мы имеем дело с, так сказать, плоскими формами - формами, не использующими вложенных компонентов, также требующих валидации. Vuelidate работает на уровне компонента, требует наличия миксина, содержит массу правил, которые нам не были нужны, но все равно тянулись в составе пакета, поддержка TypeScript и Composition API на тот момент отсутствовала, и мы не могли более с этим миритьcя.

Веб-приложение Qvault, в котором размещаются все мои курсы по кодированию, представляет собой одностраничное приложение, написанное на Vue 2, с планами перехода на Vue 3 в ближайшее время​. Тем временем я обнаружил новое классное инструментальное приложение под названием Vite, которое предложило несколько вещей, привлекших мое внимание.

Эта статья — перевод оригинальной статьи Evan You "Vue 3.2 Released!"

Мы рады объявить о выпуске Vue.js 3.2 "Quintessential Quintuplets"! Этот релиз включает в себя множество значительных новых функций и улучшений производительности и не содержит критических изменений.

Эта статья — перевод оригинальной статьи Andy Li из Vue Mastery "Vue 3 Migration Changes: Replace, Rename, and Remove (Pt. 2)".

Команда Vue недавно выпустила долгожданный билд миграции для Vue 3. Если вы думали об обновлении своего приложения с Vue 2 до Vue 3, это то, что вам нужно.

Процесс обновления приложения до последней версии фреймворка может оказаться непростой задачей. Эта серия статей создана, чтобы упростить этот процесс.

Как лучше всего структурировать приложение Vue.js, чтобы оно масштабировалось и оставалось обслуживаемым и расширяемым по мере его роста? Этот вопрос я слышал неоднократно, и думаю, что один из ответов на него кроется в принципе предсказуемости. Когда речь идет о создании масштабируемого проекта, вы хотите, чтобы все в нем было максимально предсказуемо.

Что именно я подразумеваю под предсказуемостью? В самом простом смысле, это способность интуитивно перейти от запроса функции или сообщения об ошибке к тому месту в кодовой базе, где эта задача может быть решена. Более того, это возможность быстро узнать, к каким инструментам вы имеете доступ в этом месте кодовой базы, чтобы выполнить поставленную задачу.

Почему это важно? Вы наверняка сталкивались с ситуацией, когда получали в наследство проект или были введены в него, а затем при выполнении первой задачи открывали кодовую базу и думали: "Я даже не знаю, с чего начать!".

Возможно, вы даже имели дело с кодовой базой в течение некоторого времени и возникала та же мысль! Предсказуемая кодовая база максимально облегчает этот опыт, делая знакомство разработчиков с проектами более простым, а продолжение работы - более эффективным.

Стоит отметить, что, хотя предсказуемость возможна, ни один проект никогда не станет предсказуемым на 100%. Каждый проект, новый или существующий, имеет хотя бы небольшую кривую обучения. Также следует знать, что предсказуемость не означает, что кодовая база или приложение будут быстро понятны в целом. Многие крупномасштабные приложения просто слишком сложны, чтобы это было возможно, и потребуется время, чтобы понять их целиком. Таким образом, предсказуемость - это не видение полной законченной картины, а скорее понимание структуры определенного фрагмента и возможность быстро понять, куда он встраивается. На самом деле, специфика хорошей кодовой базы такова, что ее можно понять по частям, и она не должна требовать от разработчиков необходимости думать обо всем сразу.

Миграция платежной системы в облако: Зачем и стоит ли?

Привет! Наша компания занимается разработкой платформы для процессинга электронных платежей. Платформа предоставляется в аренду по White-label модели другим компаниям, которые хотят начать бизнес в области процессинга электронных платежей, при этом получив ряд “плюшек”:

- быстрый запуск;

- готовая PCI DSS ready инфраструктура;

- дополнительная поддержка, в том числе при прохождении аудита PCI DSS;

- брендирование;

- гибкая цена.

В данной статье мы хотели бы поделиться своим опытом перехода на облачную микросервисную архитектуру, обозначить с практической точки зрения плюсы такого подхода. Материал в равной степени будет интересен как начинающим специалистам DevOps, которые хотят получить базовые представления о построении комплексных самостоятельных облачных систем, так и техническим специалистам финтех компаний, которые столкнулись с ограничениями архитектуры своих существующих решений.

Будучи одними из первопроходцев на рынке решений для процессинга электронных платежей, мы построили архитектуру платформу на базе популярных на тот момент (примерно 2012 год) и хорошо зарекомендовавших себя решений - PCI DSS ready инфраструктура с аппаратными межсетевыми экранами Cisco ASA, с сегментацией сети, использовались отдельные хосты для каждой роли - фронтенд с админкой, платежными формами, API и incoming/outgoing прокси; процессинг; хосты выдачи вакантных ключей для шифрования карточных данных; хосты с реляционными БД и т.д. Стек был тоже достаточно традиционный - PHP, Apache, MySQL.

Эта статья — перевод оригинальной статьи Andy Li из Vue Mastery "Vue 3 Migration Build: safely upgrade your app to Vue 3 (Pt. 1)".

Команда Vue недавно выпустила долгожданный билд миграции для Vue 3. Если вы думали об обновлении своего приложения с Vue 2 до Vue 3, это то, что вам нужно.

Процесс обновления приложения до последней версии фреймворка может оказаться непростой задачей. Эта серия статей создана, чтобы упростить этот процесс.

Vuex — это потрясающая библиотека управления состояниями. Она проста и хорошо интегрируется с Vue. Зачем кому-то уходить от Vuex? Причина может быть в том, что предстоящий релиз Vue 3 раскроет заложенную в ее основе систему реактивности и предложит новые способы структурирования приложения. Новая система реактивности настолько мощная, что это можно использовать для централизованного управления состояниями. 

.       .       .      

Нужно ли вам общее состояние?

Бывают обстоятельства, когда обмен данными между несколькими компонентами становится настолько сложным, что вам необходимо централизованное управление состоянием. К таким обстоятельствам относятся:

Наверно все работали с формами и понимают как это сложно. В свое время я смотрел разные решения и одним из лучших был Vuetify. Сейчас решений стало больше, но все они однотипны (я не буду брать во внимание форм генераторы). В чем то это связано с ограничением самого Vue и его философией. Но для меня все таки странно, что время идет, а прогресса нет. Странно что люди вокруг пытаются меня убедить что это нормально.

Я попытаюсь рассказать о ключевых ошибках при работе с формами и дам рекомендации как их не допустить. Также рассмотрим идеально не идеальный пример работы с формой. А выводы каждый сделает сам.

Время идет, технологии растут, а разработка тяжела на перемены. Все больше и больше ресурсов зависят от API (но нет единых стандартов и решений). До сих пор популярен REST... Что бы сделать запрос на такой сервер, необходимо задать header (auth token), указать тип запроса, адрес, задать get параметры, указать параметры в теле и тип этого тела (json/multipart). Благо есть axios и fetch и они от части решают проблему с отправкой запросов. Время идет дальше и количество запросов - которые нужно отправлять растет, а код начинает превращаться в свалку копипасты. Иногда делают мини конструкторы или обертки. Большая же часть живет по старинке.

Эта часть кода начинает жить в хранилищах (Store). В дальнейшем я буду приводить примеры на основе Vuex (Vue Store), но в целом думаю это актуально и для React и Angular. Мы разгрузим Store и перенесем все запросы в Request Manager.

Небольшой тутор о том, как передать данные из бэка на django на vue и как с помощью django сёрвить этот самый vue.

Наташа Теплухина — Open Source контрибьютор, автор документации для фреймворка Vue.js, и Staff Frontend Engineer в GitLab. Путь Наташи в индустрии начался с «Факультета информационных технологий» Национального авиационного университета Украины в Киеве, она занималась 8 лет системным администрированием, работала в маленькой студии-стартапе с WordPress и Pixel Perfect вёрсткой, а сейчас она первый Staff-инженером во фронтенде в GitLab. 

Мы расспросили Наташу как она решила заниматься Computer Science, почему начала изучать JS, какова роль участия в Open Source проектах в развитии разработчика и почему переехала в Нидерланды. А также, как проходил отбор в GitLab и о его особенностях, о прозрачности и отсутствии культуры наказаний и как она стала первым Staff-инженером во фронтенде в компании.

Linkedin

Пришлось мне как-то столкнуться с одной проблемой, а именно с проблемой, которая связана с отдачей ошибки после выката разных обновлений созданных на Vuejs + Nuxtjs в проде.

Данная ошибка возникает чуть меньше чем на минуту, но роботы кэширует это дело на всех страницах примерно на дня 2-3, из-за этого поисковиками отдаются старые мета-данные и как следствие сайт проседает в выдаче.

Надеюсь мое решение поможет многим, кто столкнется с такой же проблемой и он не будет тратить на это так много времени как я, ведь такая проблема возникает часто, если используешь Nuxt.js в режиме SSR, а описания ее решения в интернете я так и не нашел.

Данное решение уже помогло четырем компаниям избавится от этой ошибки.

Что же происходит и почему возникает такая ошибка?

Я начал разбираться. Первое что я сделал, начал анализировать, как же именно происходит процесс работы при SSR. Да, я знаю как именно он работает, но есть одна вещь..как в одной юмористической передаче.

Функции provide и inject во Vue 3 как по мне предлагают интересный подход к реализации паттерна Dependency Injection, однако принцип их работы недостаточно хорошо описан в документации. Они похожи на большой чёрный ящик с магией Vue, хотя на самом деле работают довольно просто. Я во всем разобрался, и хочу рассказать вам.

В прошлой статье меня упрекнули, что я при живом Vue 3 пишу про "устаревший" Vue 2. Отговорившись тем, что Vue 3 еще не production-ready, я понемногу начал его смотреть и изучать. И поскольку я заядлый любитель типизации и различных фичей с сахарком, то рассматривать Vue 3 с его новеньким CompositionAPI в статье именно с этой точки зрения. А заодно поэкспериментируем и попробуем написать свой типизированный store, организовать компоненты в стиле <script setup> и подружить его с typescript и eslint, а также напишем небольшой компонент на TSX в качестве еще одного эксперимента.