Привет! Готовы к короткой рабочей неделе? Давайте начнем ее с формошлепства.

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

Что делать?
Связать кнопку с формой через атрибут form.
Этот атрибут позволяет кнопке отправлять форму, даже если она расположена вне её, благодаря привязке через id.

<form id="contactForm">
  <input type="text" name="name" />
</form>

<!-- Кнопка вне формы -->
<button type="submit" form="contactForm">Сохранить</button>

Как это работает?
1. <form> получает id.
2. Кнопка вне формы указывает на этот id через атрибут form.
3. Браузер связывает кнопку с формой и корректно обрабатывает submit.

#HTML #BestPractices

Видели сайты с красивым скроллом фона? Это легко сделать самому, используя всего одно свойство CSS — background-attachment: fixed;.

Демо и код тут: CodePen

Поддержка браузерами: CanIUse

#css

С Днем Победы!

Привет! Отдохнули?) Начнем эту неделю с TypeScript. А вы знали, что в интерфейсы могут сливаться?

Пример:

interface User {
  name: string;
  age: number;
}

interface User {
  email: string;
}

const user: User = {
  name: "Григорий",
  age: 42,
  email: "mail@example.com",
};

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

Как это работает?
TypeScript объединяет все свойства из интерфейсов с одинаковыми именами в один интерфейс, позволяя вам динамически расширять интерфейсы без изменений в их исходной структуре.

Особенности:
1. Это работает только для интерфейсов, а не для типов(type).
2. Если два интерфейса имеют одинаковые свойства с разными типами, TypeScript выдаст ошибку

Пример ошибки:

interface Product {
  name: string;
  price: number;
}

interface Product {
  price: string; // Ошибка: Subsequent property declarations must have the same type.
}

В этом примере TypeScript не сможет объединить два интерфейса, потому что свойство price имеет разные типы (number и string).

#typescript

Привет! Хотя регулярность постов и изменилась, неделя по-прежнему начинается с разбора задач с собеседований)

У нас есть пример типизированого массива:

interface Student {
  name: string;
  age: number;
  hasScar: boolean;
}

const students: Student[] = [
  { name: "Harry", age: 17, hasScar: true },
  { name: "Ron", age: 17, hasScar: false },
  { name: "Hermione", age: 16, hasScar: false },
];

И дана функция поиска по массиву, которую нужно типизировать:

function getBy(arr, prop, value) {
  return arr.find(item => item[prop] === value) || null;
}

Пример использования этой функции с массивом:

const result = getBy(students, "name", "Hermione");
console.log(result);

Задача:
Типизировать функцию getBy.

Решение:

function getBy<T, K extends keyof T>(arr: T[], prop: K, value: T[K]) {
  return arr.find(item => item[prop] === value) || null;
}

1. <T, K extends keyof T> — дженерик:
- T — это универсальный тип, который представляет тип объекта внутри массива arr.
- K extends keyof T — означает, что K — это ключ объекта T. Тип keyof T — это объединение всех ключей объекта T.

2. Параметры функции:
- arr: T[] — массив объектов типа T.
- prop: K — ключ, по которому будем искать совпадение.
- value: T[K] — значение, с которым будем сравнивать. Тип значения автоматически подтягивается из типа свойства prop.


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

#JavaScript #interview #typescript

Когда мы пишем приложения, важно обеспечить их стабильность, расширяемость и простоту поддержки. В этом посте узнаем про принципы SOLID, которые помогают с этим)
Используя SOLID-принципы, вы пишете код, который легче тестировать, поддерживать и развивать.


SOLID — это аббревиатура, которая объединяет 5 принципов:

S - Single Responsibility Principle (Принцип единой ответственности)
Каждый класс или компонент должен отвечать только за одну задачу. Это упрощает тестирование и отладку, потому что если что-то идет не так, вы точно знаете, какой класс или компонент за это отвечает. Такой подход также облегчает расширение приложения, так как изменение в одном месте не затронет другие части.

O - Open/Closed Principle (Принцип открытости/закрытости)
Классы должны быть открыты для расширения, но закрыты для модификации. Это означает, что вы можете добавлять новый функционал, не изменяя существующий код. Это достигается через использование абстракций, таких как интерфейсы и наследование.

L - Liskov Substitution Principle (Принцип подстановки Лисков)
Объекты базового класса должны быть заменяемыми объектами производного класса без нарушения корректности программы. Другими словами, наследуемые классы должны вести себя как их базовые классы, чтобы не ломать логику приложения.

I - Interface Segregation Principle (Принцип разделения интерфейсов)
Не стоит создавать универсальные интерфейсы, которые будут иметь множество методов, не используемых в разных классах. Лучше создавать несколько более специализированных интерфейсов. Это уменьшает зависимость классов и облегчает поддержку кода.

D - Dependency Inversion Principle (Принцип инверсии зависимостей)
Высокоуровневые модули не должны зависеть от низкоуровневых, а обе эти категории должны зависеть от абстракций. Это позволяет сделать код гибким и менее зависимым от конкретных реализаций.

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

#BestPractices