10 советов для написания чистого кода на Vue.js

1. Разумное использование Composition API. Разделяйте большой код на небольшие, многократно используемые компоненты для поддержания модульности и читаемости.

2. Следуйте соглашениям об именовании в Vue. Используйте PascalCase для имен файлов компонентов и, при необходимости, kebab-case для использования в шаблонах.

3. Избегайте чрезмерного использования Vuex или Pinia. Держите временные состояния интерфейса (например, видимость модальных окон) локальными для компонента, а не в глобальном управлении состоянием.

Пример: Используйте ref или reactive для временных состояний.

4. Эффективное использование слотов. Используйте именованные слоты для большей гибкости в многократно используемых компонентах и документируйте их использование.

Пример: Создайте компонент Card с <slot name="header"></slot> для настраиваемых заголовков.

5. Использование Scoped Styles. Используйте scoped стили в <style scoped> для предотвращения конфликтов CSS.

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

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

Пример: Вместо жесткого кодирования кнопки, создайте настраиваемый компонент Button, поддерживающий пропсы для различных стилей.

7. Обработка асинхронного кода. Используйте async/await для API-запросов и обрабатывайте ошибки с помощью центральной функции.

8. Документирование пропсов и событий. Ясно определяйте и документируйте пропсы и события, используя аннотации props и emit или TypeScript.

Пример: Используйте defineProps и defineEmits в Vue 3 для ясности и безопасности типов.

9. Линтинг кода. Настройте ESLint и Prettier с Vue-специфическими конфигурациями для обеспечения качества и согласованности кода.

10. Упрощение шаблонов. Избегайте сложной логики в шаблонах; вместо этого используйте вычисляемые свойства или методы.

Пример: Замените `v-if="list.filter(item => item.active).length > 0"` на вычисляемое свойство `activeItems`.

(с) dev.to

#tip #bestpractices

Пример "протекания" стилей во Vue 3 при scoped styles от Artyom Tuchkov

// A.vue
<div class="a" />

// B.vue
<div class="b">
  <div class="a">
    <A /> // oops
  </div>
</div>

Playground

Нужно хорошее семантическое наименование классов, чтобы не попасть в такую ситуацию

#css

Предлагаю поделиться в комментариях тремя вещами, которые делают вашу работу комфортной и эффективной. Что-то неординарное, а не такое банальное и мастхэвное, как Vite, например.

Начну:

1. Remote разработка на мини пк
2. Cursor IDE (AI помощник)
3. @sxzz/eslint-config

#dx

Кто занимается микрофронтендами - познавательная статья Micro Frontends на сайте Мартина Фаулера

#microfrontends #architecture #bestpractices

Комментарии к прошлому посту ярко показывают, стоит ли тащить в свой проект чудо природы под названием FSD.

Модульная архитектура даёт понятную четкую декомпозицию проекта, хорошо разделяя ShoppingCart от UserAccount, например. Позволяя видеть в файловой панели только относящиеся к нужному модулю ресурсы, и работать над модулями независимо.

Общие элементы типа BaseButton можно держать в App, а можно выделить под них отдельный проект (вроде своей дизайн системы) и подключать папкой ui через git submodules. Так же, как и объекты типа api.

Между модулем и однофайловым компонентом есть промежуточные структуры - виджеты типа FileUploader, например, в которых есть чисто их композаблы, утилиты, компоненты, типы. Их удобно держать в своих папках без разделения по поддиректориям.

Довольно сложный вопрос, где держать и как наименовать файлы с бизнес-логикой - как реактивной, так и обычной. Однозначного совета пока нет. Скорей тут надо использовать программерские подходы из обычного ООП.

#architecture

Одна из проблем при разработке нативных js бандлеров типа Rolldown и Rspack - они должны работать в WASM для возможности их запуска в браузере ( StackBlitz, Bolt.new и т.п.)

Это довольно сложно реализовать, и Rspack отказался от этого. Но Rolldown, по словам Эвана Ю, будет поддерживать билд в браузерных средах и уже показывает хорошую производительность в них.

#rolldown #rspack

Несколько цитат о TypeScript

«TypeScript - это куча лишней работы для решения проблем, которых у меня нет, способами, которые мне не нравятся».

Kyle Simpson, автор очень влиятельной серии книг «Вы не знаете JS».

«Мы переписали нашу кодовую базу на TypeScript и стали получать на 30 % больше багов».

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

«95 % того, что дает TypeScript, можно сделать с меньшими усилиями и инструментами, просто используя строгий линтинг и JSDocs».

«Я просмотрел всего около 10 кодовых баз TypeScript, но ни в одной из них я буквально не смог прочитать код. Он настолько уродлив и плохо продуман. Какое чудовище придумало это?»

«У JavaScript есть проблемы. Если вы работаете с ним достаточно долго, вы столкнетесь с ними, и вам нужно будет найти способ их решить. TypeScript решает большинство из этих проблем «из коробки». Поэтому он может хорошо подойти тем, кто пришел с другого языка и не заинтересован в глубоком изучении JavaScript»

«Я беспокоюсь, что те новые разработчики, которые хотят со временем стать JavaScript-разработчиками, будут лишены возможности научиться обходить опасности JavaScript, имея при этом доступ к возможностям свободно типизированного языка. Я вижу, как они находят TypeScript и используют его как костыль, не понимая, на что способен JavaScript в полной мере.»

Источник

#typescript #quote