About Teletype
Join
Shohzod Tursunov
@sheyxuz
November 10, 2025

Code Writing Rules (Vue, TypeScript)

Perfect! Here's your beautified code writing rules with proper TypeScript/JavaScript/Vue code block formatting:

1. Vue

1.1. Общие правила Vue

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

1.2. Нейминг

1.2.1. Названия событий в интерфейсах с суффиксом Emits именуем через camelCase. Правило есть и в документации Vue. Пример:

// ❌ Некорректно
interface Emits {
  (event: 'do-something')
}

// ✅ Корректно
interface Emits {
  (event: 'doSomething')
}

1.3. Watch

1.3.1. Стараемся не писать, если можно избежать - избегаем. Почему watch не есть хорошо?

  • watch реагирует на любые изменения состояния. Если разработчику нужно, чтобы сайд-эффект работал только при определенных условиях, например при изменении состояния через дочерний компонент, но не при изменении в самом родительском компоненте, то нам нужно заводить внутри watch костыль для проверки данного условия;
  • watch создает неявные связи между состоянием и побочными эффектами, что затрудняет отслеживание логики приложения, которая размазывается по компонентам;
  • Множественные watch-обработчики действуют как независимые точки входа, усложняя понимание потока данных. Когда нужна последовательность действий вместо параллельных, требуется рефакторинг.

Альтернативное решение: использовать явные методы обновления состояния — единые точки входа, через которые происходят все изменения. Это делает поток данных предсказуемым и упрощает добавление последовательной логики.

Вместо реактивного "что-то изменилось → автоматическая реакция" лучше императивный подход "вызываю конкретный метод → контролируемое изменение состояния".

1.4. Components

1.4.1. Вместо USpace используем легковесный UFlex, но если вам нужно просто wrapper не злоупотребляйте UFlex а пишите просто div

1.4.2. Названия компонентов пишем подробнее: указываем, что делает компонент и к какому модулю он относится.

CashbackModal.vue // ❌ Некорректно

CashbackOpenModal.vue // ✅ Корректно

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

// some-component/some-component.types.ts
export interface SomeComponentProps {}
export interface SomeComponentEmits {}

// some-component/useSomeComponent.ts
export default function useSomeComponent(
  props: SomeComponentProps,
  emit: SomeComponentEmits
) {
  return {};
}

// some-component/SomeComponent.vue
// Максимально стараемся поставить спейс и разделить блок кода от друг друга
<script lang="ts" setup>
import { SomeComponentProps, SomeComponentEmits } from './some-component.types';
import useSomeComponent from './useSomeComponent';

const props = defineProps<SomeComponentProps>();
const emit = defineEmits<SomeComponentEmits>();

const {} = useSomeComponent(props, emit);
</script>

// some-component/index.ts Всегда указываем название как as
export { default as SomeComponent } from './SomeComponent.vue';

1.4.4. Всю логику компонента выносим в основной композабл как в примере 1.4.3, в теге script не реализовывем никакую логику, кроме использования макросов и основного композабла.

1.4.5. Стараемся не реализовывать новые общие компоненты в shared/components и shared/UI, вместо этого ищем готовые локальные решения и компоненты в uzum-ui. Если не нашли компонент, то можно уточнить у коллег фронтов и в случае отсутствия дать заказ на разработку компонента в uzum-ui.

1.4.6. Если считаете что root div не нужно можно его убрать + style tag тоже если в компоненте нету доп стили

1.4.7. Пример как должен быть код стайл use composable файл внутри:

  • объявление use функции или примитивные константы (use fn, const)
  • ref/reactive
  • computed
  • arrow fn, declarative fn
  • Vue hooks

2. JavaScript

2.1. Общие правила JavaScript

  • Всегда стараемся писать точку запитую (;), это означает что блок кода закончен.
  • Стараем писать стрелочные функции вместо декларативных если в коде не нужно hoisting
  • Прямую доступ к DOM через JavaScript не пишем а вместо его используем Vue ref

2.2. Нейминг

2.2.1. Все называем через camelCase, кроме: классы через PascalCase, примитивные константы через UPPER_CASE

2.2.2. Не ставим "лишний camelCase", к примеру вместо withOut, withIn пишем without, within, и тд

2.3. Функции

2.3.1. Декларативные функции объявляем после стрелочных

2.3.2. Стараемся не писать односложные функции таких как (close, open, delete), а вместо этого стараемся писать (closeModal, openModal, deleteDocument).

2.4. Классы

2.4.1. В одном файле может быть только 1 класс

2.4.2. Название класса должен соответствовать с названием модула

3. TypeScript

3.1. Общие правила TypeScript

3.1.1. Все типы выносим в {name}.types.ts файл

3.1.2. Порядок объявления типов - enum, interface, type

3.1.3. Не задаем тип через обращение к полю интерфейса, если этот интерфейс не находится в 1ом и том же файле. Пример:

// users.types.ts
export interface User {
  name: string;
  age: number;
}

// users-utils.ts
export const getAgeByName = (name: User['name']): User['age'] => ''; // ❌ Некорректно

// users-utils.ts
export const getAgeByName = (name: string): number => ''; // ✅ Корректно

3.1.4. Если интерфейс эмитов напрямую зависит от интерфейса пропсов, при этом оба расположены в 1ом файле типов, то связываем поля интерфейса эмита с полями пропсов напрямую. Пример:

// some.types.ts
export interface Model {
  name: string
}

// some-component.types.ts
export interface SomeComponentProps extends Model {}

export interface SomeComponentEmits {
  (event: 'update:name', value: SomeComponentProps['name'])
}

3.1.5. Не пишем вложенные интерфейсы. Если они вложены, то выносим их отдельно:

// ❌ Некорректно
interface User {
  info: {
    genderId: number
  }
}

// ✅ Корректно
interface UserInfo {
  genderId: number
}

interface User {
  info: UserInfo
}

3.1.6. Что типизируем? - Типизируем все, но есть Исключения:

// Функция уже возвращает типизированное значение
const result = getResult();

// Значение переменной является примитивом
const primitive = 1;

// Возвращаемый тип композабла, store в том числе
const useComposable = () => {};

// Объектные константы можно типизировать через as const. Примитивные константы не типизируем через as const, они и так будут типизированы как as const
const someConfig = {} as const;

// Если ref во vue является булев типа и вы передали значение по умолчанию
const isActive = ref(false);
const isBlocked = ref<boolean | undefined>(); // Если нет значения по умолчанию и тип может быть не только булев, то задаем тип конкретно

3.2. Нейминг

3.2.1. Все ключи Enum должен быть всегда Pascal Case

3.3. Enum

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

// ❌ Некорректно
enum State {
  Active,
  Inactive
}

// ✅ Корректно
enum State {
  Active = 0,
  Inactive = 1
}

3.3.2. Всегда стараемся писать const Enum чтобы кусок кода в рантайм не попал

4. Организация модулей/кода

4.1. Общие правила

4.1.1. В index.ts кладем только ре-экспорты

4.2. Форматирование

4.2.1. Код должен полностью соответствовать настройкам линтеров

4.2.2. В коде не должны быть: лишние переносы, лишние отступы, лишние пробелы

4.3. Дизайн система

4.3.1. Все цвета должны находится в Дизайн системе, иначе просим дизайнеров поправить цвет в макете

5. Общие правила

5.1. Все что: не рекомендуется, лучше не делать, стараемся не писать и тп - допускается только в случаях, когда:

  • других вариантов нет;
  • решение четко и подробно обосновано, и приложен хотя бы 1 пример;
  • перечислены преимущества и недостатки обоих подходов;
  • решение согласовано с Лидом.

5.2. Любые несоответствия с вышеописанными правилами, нужно:

  • четко и подробно обосновать, и приложить примеры для обоих подходов;
  • перечислить преимущества и недостатки обоих подходов, так же с примерами;
  • согласовать с Лидом.

5.3. Review кода:

  • четко и подробно написать комментарии и обязательно пусть сам ревьюер делает резолв;
  • не ставить аппрув прежде чем разработчик не смотрел или не объяснил ситуацию с комментом.

6. Общие правила CSS

6.1. Нужно обязательно ставить точка запитую после стeйтмент

.example {
  color: red;
  padding: 10px;
}

7. Общие правила хранение файлов в проекте

7.1. Картинки прогонять через squoash.app или tiny img и храним в public/images

@shahzodcodes follow

https://tirikchilik.uz/@sheyxuz - Donat uchun agar foydali bo'lgan bo'lsa

Shohzod Tursunov
November 10, 2025, 06:51
0 views
4 reactions
0 replies
0 reposts