VueJS *

Аргументация против глобальных автоимпортов (типа тех, что в Nuxt)

1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в *.d.ts ;)

2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент

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

4. Не нужно генерировать портянку *.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода

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

6. Импорты может проставлять сама IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают

Источник

Разница между адаптивностью (слева) и отзывчивостью (справа)

Во Vue 3, чтобы выделить из компонента отдельно некий функционал с реактивным состоянием, были созданы composable функции (называемые "функциями", хотя по сути это объект созданный через js замыкание - closure).

Чтобы использовать функционал с реактивным состоянием между несколькими компонентами, можно задействовать js модули либо Pinia/Vuex сторы.

Иногда нужно нечто среднее - подобную сущность с реактивным стейтом и функционалом на нем, но используемую в нескольких связанных компонентах (например, в Tabs или каких-то виджетах), - то есть, в некотором локальном контексте. Для этого можно в общем родительском компоненте создать composable, который передать потомкам - либо через provide/inject (лучше), либо через props (не надо).

В этом случае данный реактивный объект будет жить в своем ограниченном контексте и не будет конфликтовать с оставшейся частью проекта.

// Vue 3
const app = createApp(App);
app.config.errorHandler = (err) => {
  alert(err);
};

Во Vue можно создать собственный обработчик ошибок и ворнингов для лучшей обработки ошибок для улучшения UX.

Например, вместо того, чтобы приложение падало, если ошибка не была обработана, вы можете показать специальный экран ошибки и попросить пользователя обновить страницу или сделать что-то еще.

Обработчик ворнингов работает только в dev режиме.

29 и 30 июня 2024 года Certificates.dev бесплатно на 48 часов откроет доступ к тренировочным материалам на соискание ученой степени Certified Vue.js Developer.

Включает в себя теорию, задачи по кодированию и пробный экзамен.

------

Наш Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.

Во Vue 3 есть важная и нередко используемая конструкция, у которой нет имени. Это то, что обычно называют "композабл с глобальными рефами".

Но:

1. Это не композабл по определению

2. Там не обязательно рефы

3. Они не "глобальны"

В общем случае структура данного объекта - экспортируемые из ES модуля реактивные данные и функции для работы с ними.

Функционально они заменяют "сторы" Pinia. Называть их тоже stores - двусмысленно и нелогично. Вообще, молиться на "глобальный стейт" после появления идеи JavaScript signals и их всевозможных реализаций, включая Vue Reactivity API, архаично.

Мне кажется, самое подходящее название для данной конструкции - [реактивный] бизнес объект (РБО) или Vue Business Object (VBO). В них инкапсулируется логика предметной области и приложения, они не привязаны к конкретным компонентам, и по аналогии с другими языками и фреймворками, этот паттерн - Business Object, - выглядит вполне подходящим.

Техническая реализация может быть через ES классы, ES модули, closures, Pinia stores, с использованием singleton или DI.

Кроме того, позиционирование именно как "бизнес объект" будет требовать явного отделения от него презентационного и инфраструктурного слоев - работы с Backend API, например. То есть, стимулировать использование лучших практик и наработок из других сфер разработки ПО, еще более переводя Vue.js из фреймворка для небольших проектов в разряд enterprise level решений.

--------------

Telegram-канал о Vue и фронтенд-разработке: @vuefaq и вебсайт: Vue‑FAQ.org.

Состоялся выпуск второй мажорной версии инструментария vue-ray. Исходный код проекта опубликован на GitHub под лицензией MIT.

Предыдущая стабильная версия проекта vue-ray v1.17.4 вышла в мае 2023 года.

Проект vue-ray позволяет проводить отладку кода Vue с помощью Ray, чтобы быстрее устранять проблемы. Установите этот пакет в любой проект Vue 3, чтобы отправлять сообщения в приложение Ray.

Q-OTP - двухфакторная аутентификация на VueJS.

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

Компонент подключается как Quasar App Extension:

quasar ext add q-otp

Пример подключения:

<template>
  <QOtp
      field-classes="q-ml-xs q-mr-xs"
      @complete="(code) => alert(code)"
  />
</template>
<script lang="ts" setup>
  import QOtp from 'quasar-app-extension-q-otp'
</script>

Исходный код доступен на Гитхаб под лицензией MIT.

Продолжается перевод книги Vue.js 3 Design Patterns and Best Practices

На данный момент переведено 6 глав:

• Глава 1, Фреймворк Vue 3

• Глава 2, Принципы и шаблоны проектирования программного обеспечения

• Глава 3, Создание рабочего проекта

• Глава 4, Композиция пользовательского интерфейса с помощью компонентов

• Глава 5, Одностраничные приложения

• Глава 6, Прогрессивные веб-приложения

Богатый набор компонент, но..

• Медленная работа

• Огромный вес

• Слабая кастомизируемость

• Сомнительные практики

Мелкозернистая ленивая реактивность, но..

• При всплытии исключения компонент просто исчезает.

• Нет отсечения эквивалентных изменений.

• Неконсистентное состояние при циклических зависимостях.

С полу слова понимаем друг друга:

Та же проблема и в Ангуляре.

И только один фреймворк понимает с первого раза.. но я вам его не покажу.