Pinia vs Vuex: Ананасовый экспресс сижу код пишу!
Pinia, легковесная библиотека управления состояниями для Vue.js, приобрела популярность в последнее время. Она использует новую систему реактивности во Vue 3 для создания интуитивно понятной и полностью типизированной библиотеки управления состояниями.
После jQuery я попробовал AngularJS и был очарован его возможностями. Несколько строк в AngularJS заменяли кучу спегетти-кода в jQuery. Это было похоже на магию. Сейчас все современные Frontend-фреймворки так или иначе обеспечивают реактивность, и это уже никого не удивляет. Тем не менее далеко не все разработчики понимают, как это работает.
Сейчас я работаю с Vue, поэтому и разбираться с тем, как устроены реактивные функции, будем на его примере. Я расскажу, как сделать из простого объекта реактивный, а также немного о том, какие современные возможности JS для этого используются.
Vitest — это новая среда тестирования на базе Vite. Он все еще находится в разработке, и некоторые функции могут быть еще не готовы, но это хорошая альтернатива, которую можно попробовать и изучить.
Модальные диалоги не такая и сложная задача в разработке. Обычно это очень монотонная и неинтересная работа с повторяющейся логикой, которую подчас копируют из компонента в компонент с незначительными изменениями. Часто используется для подтверждения пользователем каких-либо действий. Например удалить какие-либо данные или выполнить авторизацию.
Но что делать, если у вас десятки или даже сотни похожих диалогов на одной странице или даже во всем проекте? Или нужно вызывать диалоги по цепочке в зависимости от выбора пользователя? Как абстрагировать такой функционал и не получить в результате запутанный и плохо поддерживаемый код?
Вы когда-нибудь задумывались о селекторе CSS, где вы проверяете, существует ли конкретный элемент внутри родителя? Например, если у компонента карты есть миниатюра, нам нужно добавить к нему display: flex. Это было невозможно в CSS, но теперь у нас будет новый селектор CSS :has, который поможет нам выбрать родителя определенного элемента и многое другое.
В этой статье я объясню проблему, которую решает :has, как он работает, где и как мы можем его использовать с некоторыми вариантами использования и примерами, и, самое главное, как мы можем использовать его уже сегодня.
Кто бы что не говорил о метриках производительности, мол это все ерунда и никому кроме гугла не нужно. Но, во-первых, я так не считаю, а во вторых у нас есть заказчики, которым это важно
и они задачи по оптимизации производительности нам ставят, и, даже если по Вашему высокопрофессиональному мнению они заблуждаются, то делать их надо.
Не буду пересказывать рекламные лозунги про 500% пользователей покидают страницу после 100мс ожидания, увелечения конверсии на 20% при снижении LCP на 2мс… читайте сами. Скажу коротко: метрики производительности важны.
За последние несколько лет управление состоянием в React претерпело значительные изменения. Многие перешли с Flux на Redux и ищут еще более простые решения. Кроме того, появление React Hooks открыло новые возможности для управления состоянием.
Некоторые из новых библиотек управления состоянием, которые появились на горизонте, — это Recoil, Jotai, Radio Active state и Zustand.
В этой статье я расскажу о Zustand, который предоставляет легкий и простой способ управления состоянием в React.
В статье ставится проблема избыточной сложности использования фреймворка React.js при богатстве его функций, описана возможная тенденция роста технического долга и зависимость между предоставляемыми средствами и величиной технического долга.
Что подразумевается под необоснованной сложностью проектов?
Для начала необходимо отметить, что «React» в отличии от «Vue» предоставляет огромную свободу разработчику. Благодаря этому разработчики любят данный фреймворк и всячески указывают, что приложения на «React» будут быстрее и производительнее чем на «Vue». Это несомненно так, «React» приложения можно сделать быстрым, производительным и легко тестируемым. К сожалению, достичь этого крайне тяжело и из-за этого многие компании могут иметь не высокопроизводительные приложения, а наоборот перегруженные излишним кодом и трудно тестируемые приложения. Это связанно с тем, что начинающим разработчикам сложно понять, как правильно писать приложения на «React».
«React» словно тренер по плаванию, бросает вас в воду и говорит плыви, ему не важно будете вы правильно дышать или махать руками, ему важно чтобы вы плыли. Проецируя данный пример на «React», мы получаем возможность писать очень плохой рабочий код. Особенно это распространено в командах, где нет специалиста по «React». Люди меняются и каждый раз поддерживать приложение все труднее и труднее, кто-то увидел пример в функциональном стиле:
В 2015 году, когда я пришёл на своё текущее место работы, мне было непривычно от необыкновенной свободы действий. Буквально, на новом месте можно было проявить весь творческий потенциал как DevOps-евангелиста. Мне нравилось выстраивать процессы, автоматизировать рутину, делать разработку удобной. Больше всего я люблю оптимизации, а больше всего ненавижу - рутину.
Эта история одной боли и попытке не просто "принять обезболивающее", а реально излечить её. Поэтому готовьтесь переварить лонгрид.
Всем привет!
Сегодня хотел поделиться несколькими фишками в работе с i18n.
i18n – это фреймворк для интернализации веб-приложении. То есть, при помощи данного фреймворка мы легко можем реализовать мультиязычность в веб-приложениях.
Nuxt.js мощный инструмент для разработки веб-приложений. Помимо того, что он из коробки предоставляет много полезных утилит и инструментов, также, есть много дополнительных модулей из community, которые позволяют легко интегрировать разные инструменты в Nuxt.js. Посмотреть на сторонние модули для Nuxt.js можно здесь.
Привет, друзья!
В этой статье я продолжаю (и заканчиваю) делиться с вами заметками о Docker.
Заметки состоят из 4 частей: 2 теоретических и 2 практических.
Если быть более конкретным:
Docker, Docker CLI и Dockerfile;Docker Compose;В этой заключительной части мы "контейнеризуем" наше приложение.
Репозиторий с кодом приложения.
Если вам это интересно, прошу под кат.
В идеале Vue-компоненты представляют собой самодостаточные части пользовательского интерфейса без каких-либо заметных побочных эффектов для объектов за пределами области действия данного элемента. Но, к сожалению, это не всегда возможно. Например, иногда нам нужно связать глобальных слушателей событий, использовать setInterval или инициализировать определенную стороннюю библиотеку внутри компонента.
В тот момент, когда вы набираете что-то на клавиатуре, читаете файл с диска или скачиваете его через Интернет, поток информации (биты) проходит через различные устройства и приложения.
Если вы научитесь работать с этими потоками битов, то сможете создавать высокопроизводительные и полноценные приложения. Например, вспомните, как просматривается видео на YouTube. Необязательно ждать, пока загрузится весь видеоролик. Как только в буфер попадает небольшой фрагмент, он начинает воспроизводиться, а остальное продолжает загружаться по мере просмотра.
Разработка веб-приложения это не только решения интересных задач, работа с логикой, или с интересной версткой. Это также рутина, которая преследует каждого разработчика в процессе работы. Начиная от создания разных файлов, и написания шаблонного boilerplate кода, заканчивая написанием документации о проделанной работе.
Часть этой рутины, однако, можно всегда оптимизировать.
В этой статье хочу познакомить вас с инструментом, который разработал, для минимизации рутины при создания компонентов Vue.js – VGENT.
VGENT (Vue Agent) – это CLI (Command Line Interface) приложение, которая генерирует компоненты для фреймворка Vue.js или Nuxt.js. Данный инструмент можно гибко настроить под нужды проекта, и генерировать компоненты командами в терминале.
Думаю, что сейчас необходимость статической типизации фронтенд приложений не вызывает сомнений, не буду описывать все ее плюсы и минусы, так как на Хабр уже неоднократно обсуждалась данная тема. В данной статье бы хотел предложить решение, которое позволит выполнять проверку типов при создании HTML разметки во Vue.
Привет, друзья! Продолжаю делиться с вами заметками о Docker.
Заметки состоят из 4 частей: 2 теоретических и 2 практических. Если быть более конкретным:
Docker, Docker CLI и Dockerfile;Docker Compose.В этой части мы разработаем простое приложение, состоящее из трех сервисов и базы данных, а в заключительной — "контейнеризуем" его.
Репозиторий с кодом приложения.
Если вам это интересно, прошу под кат.
Перед новым годом по мере нарастания стресса на работе я стал проводить много времени в Твиттере.
Это было моё последнее пристанище после почти годовой деактивации Фейсбука, ВКонтакте и Инстаграма.
Автоматический статус ВК после отключения аккаунта хорошо передавал суть моего положения: «Я не могу жить и работать, пока в интернете есть страница с моим именем».
Твиттер я никогда не понимал, завел по рекомендации Ситника, и стал вести его осенью на английском языке. Подписывался только на коллег, узнал много интересного, но вскоре и он превратился в обычную соцсеть с болтовней, флиртом и сотнями друзей.
Но мне было стыдно удаляться и оттуда. Получится -- убежал отовсюду, оставив после себя пустое место. Соцсеть это всё-таки связь с людьми, и даже с потенциальными клиентами.
В этой серии вы узнаете как собрать докер-образ приложения на Vue.js и как опубликовать его в GitHub Packages. Вот так. Вот в общем-то и... не всё... Одним GitHub Action, как это было для Spring Boot приложения, о котором я рассказывал тут, в этот раз обойтись не получится. Нужно ещё проделать некоторые манипуляции, о которых я и расскажу в данной статье.
В этой статье будут изложены основные идеи и показаны простые примеры для грамотной организации, скажем так — «репликационного» масштабирования проектов на фронтенде. То есть, само понятие масштабирования здесь будет рассматриваться скорее с той точки зрения и в одном из смыслов как это понимает бизнес, но, при этом, речь пойдет именно о технической стороне процесса, правда, сугубо в контексте браузерной клиентской части информационных систем. Ближе к реальной ситуации: предположим что ваша компания разрабатывает, условно — некий OLAP-продукт, и перед вами как фронтенд-разработчиком ставят задачи по развертыванию и поддержке более или менее сходных новых проектов фронтенда для разных заказчиков. После скандальной критической статьи о, имхо, сомнительных дурных современных подходах и тенденция в верстке веб-интерфейсов — моя карма на Хабре, наконец-то упала ниже нуля, а я, если честно, не очень хорошо понимаю правила игры, увидят ли эту статью читатели… Но, с другой стороны, готов изложить все просто «в стол», так как считаю что лучшая мотивация для написания чего-либо — это если «просто очень хочется написать», сформулировать, прежде всего — для себя самого.
Эта статья логично продолжает тематику первой статьи о модулях позволяющих сделать разработку фронтенда качественнее и эффективнее. Но если в первом материале речь шла, прежде всего, об замечательном атомарном тренде в вебдизайне и простом надежном способе доставки его в код компонентных фреймворков с помощью препроцессоров, построении простой кастомной библиотеки UI-компонент для единообразного оформления разных проектов, то новый пример станет немного сложнее — хочется сосредоточиться уже не на «внешних», «оформительских» моментах, а на функциональных и организационных. Для наглядной демонстрации практического применения изложенных в статье идей снова написаны примеры: небольшой модуль-библиотека (и документация к нему), а также использующий его проект, на этот раз с более актуальным стеком Vue3+TypeScript/Vuex4/VuePress2. В отличие от более примитивной либы из первой статьи, этот модуль: 1) использует хранилище, то есть содержит состояние 2) может запускаться в полноценном режиме разработки, как будто это собственно уже сам конечный проект 3) поддерживает темизацию и локализацию. Пример модуля содержит совсем немного компонент и документация на новой версии VuePress, в отличие от первой версии модуля, не кастомизируется под фирменный стиль который предоставляет сама библиотека. Так сделано не только по причине лени и экономии времени, но, прежде всего, потому что кажется излишним — то что призваны продемонстрировать примеры — этого совсем не требует.
Привет, хабрист!
Довольно давненько подружил свои приложения с гуглом.
Основная идея была - не создавая новых шаблонов, получить все страницы сайта AMP-friendly и, вообще, сделать ядро приложения AMP-ready.
Тут нас поджидает серьезная переработка стилей CSS и структуры приложения путем добавления дубликатов забаненных гуглом компонентов, таких как картинки, карусели, менюхи и прочее.
Я буду вещать на примере самого простого - картинок. Все прочее аналогично, хоть и посложнее на практике.
Объявим зависимости