Друзья, рад вам представить результат трудов последних месяцев — полноценный, бесплатный фронтенд роудмап, оформленный в мини приложение в телеграм!
Мы с Димой старались сделать его максимально простым и удобным, но при этом полезным для каждого фронтенд-разработчика.
Что внутри?
Это приложение — полноценная дорожная карта по фронтенду, начиная от HTML, заканчивая материалами по System Design:
Подойдет как для новичков, так и для уже бывалых: вы сможете найти новые инструменты и подходы, добавив что-то полезное в свой стэк с помощью финальных блоков.
Мы планируем поддерживать и развивать этот роудмап, актуализируя материалы, добавляя новые практики и актуальные задачи.
💡 Сохраняйте себе и обязательно делитесь с теми, кому это может быть полезно!
P.S: любые пожелания, мнения и доработки — приветствуются!)
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥36🎉14❤12👍2
Топ самых популярных вопросов на frontend собеседованиях за 2025 год!
Я проанализировал записи и разборы сотни собеседований студентов за весь текущий год, чтобы составить список самых частотных/популярных вопросов, которые встречаются на собеседованиях сейчас.
ВАЖНО: я не делил их по грейдам и зарплатным вилкам. Интересно было посмотреть именно на общую частотность.
Самая популярная секция вопросов оказалась именно софтовая и это не удивительно: я брал записи как скринингов с эйчарами, так и полноценные технические собеседования, поэтому вопросы по типу "расскажи о себе" встречаются практически в ста процентах случаях и там, и там.
Дальше по популярности идет JavaScript, что тоже не удивительно, ведь это основная технология фронтенд разработчика и все последующие фреймворки и технологии вытекают именно из нее.
Далее по популярности уже идут вопросы про основной фреймворк. У нас перевес собеседований идет больше в сторону Vue.js, но составил отдельные списки для двух фреймворков.
Из интересного: вопросы, связанные с архитектурой стали встречаться достаточно часто (12% от всех вопросов), что говорит о том, что рынок постепенно перенасыщается разработчиками, которые умеют лишь “красить кнопки”, и всё сильнее растёт запрос на инженеров, владеющих архитектурными практиками и способных писать масштабируемый и поддерживаемый код.
Теперь к самим вопросам. Разбил их по группам для удобства.
HR / soft skills (26-28% всех вопросов)
JavaScript (22–24%)
Framework (18–20%). Vue.js
Так как пост имеет ограничение на количество символов, оставшиеся группы:
- React (18-20%);
- TypeScript (12-14%)
- Архитектура (10-12%)
- Тестирование (5-6%)
- HTML / CSS (5-6%)
- Сеть / Web / Браузер (4-5%)
- CI/CD / DevOps (3-4%)
можно забрать со всеми вопросами файлом через нашего бота, написав специальную команду
✈️ Telegram | 🎓 Менторство | 📹 YouTube | 👩💻 Roadmap
Я проанализировал записи и разборы сотни собеседований студентов за весь текущий год, чтобы составить список самых частотных/популярных вопросов, которые встречаются на собеседованиях сейчас.
ВАЖНО: я не делил их по грейдам и зарплатным вилкам. Интересно было посмотреть именно на общую частотность.
Самая популярная секция вопросов оказалась именно софтовая и это не удивительно: я брал записи как скринингов с эйчарами, так и полноценные технические собеседования, поэтому вопросы по типу "расскажи о себе" встречаются практически в ста процентах случаях и там, и там.
Дальше по популярности идет JavaScript, что тоже не удивительно, ведь это основная технология фронтенд разработчика и все последующие фреймворки и технологии вытекают именно из нее.
Далее по популярности уже идут вопросы про основной фреймворк. У нас перевес собеседований идет больше в сторону Vue.js, но составил отдельные списки для двух фреймворков.
Из интересного: вопросы, связанные с архитектурой стали встречаться достаточно часто (12% от всех вопросов), что говорит о том, что рынок постепенно перенасыщается разработчиками, которые умеют лишь “красить кнопки”, и всё сильнее растёт запрос на инженеров, владеющих архитектурными практиками и способных писать масштабируемый и поддерживаемый код.
Теперь к самим вопросам. Разбил их по группам для удобства.
HR / soft skills (26-28% всех вопросов)
1. Расскажите о себе и вашем опыте.
2. Как пришли в IT?
3. Почему выбрали фронтенд/вашу специализацию?
4. Где работали ранее, почему уходите с текущего места?
5. Опишите вашу команду, как строили взаимодействие.
6. Как справляетесь со стрессом/неудачами?
7. Как предпочитаете работать: удаленно, гибрид, офис?
8. Что мотивирует вас в работе/развитии?
9. Ваши сильные стороны как специалиста?
10. Каких целей хотите достичь в компании?
JavaScript (22–24%)
1. Чем отличаются var, let и const?
2. Как работает event loop в JavaScript?
3. Что такое замыкание (closure), приведите пример.
4. Объясните механизмы async/await, Promise, callback hell.
5. Как устроено наследование, прототипы?
6. Для чего нужны map, reduce, filter? Покажите отличие от forEach.
7. Что делает bind/call/apply?
8. Как работает оператор spread/rest?
9. Отличие стрелочной функции от обычной.
10. Как работает this и как его менять?
11. Что такое async / defer?
12. Клонирование объектов
13. Что такое Set, Map
14. Задачи на строки и массивы
15. Что такое NaN?
Framework (18–20%). Vue.js
1. Чем отличаются ref / reactive / shallowRef?
2. Как устроен жизненный цикл компонента в Vue?
3. Отличие Vue 2 и Vue 3.
4. Что такое Composition API и Options API? Когда применять каждый из них?
5. v-if / v-show
6. Как работают computed и watch?
7. Что такое Virtual DOM во Vue и как работает?
8. Что такое Composables, приведите примеры
9. Как устроен роутинг (router)?
10. Как работает состояние (state), Vuex vs Pinia?
11. Как реализовать SSR в Nuxt/Vue / гидраций / почему и когда нужно?
12. Что такое props, как их типизировать?
13. Как устроен v-bind, v-model, v-html?
14. Что такое slots и зачем нужно?
15. Как оптимизировать производительность / keep-alive / nextTick
Так как пост имеет ограничение на количество символов, оставшиеся группы:
- React (18-20%);
- TypeScript (12-14%)
- Архитектура (10-12%)
- Тестирование (5-6%)
- HTML / CSS (5-6%)
- Сеть / Web / Браузер (4-5%)
- CI/CD / DevOps (3-4%)
можно забрать со всеми вопросами файлом через нашего бота, написав специальную команду
/questions.Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥30❤8✍8👍8 1
Forwarded from Путь к CEO (18+) | Борцов Дмитрий
ух.. Последний пост от 22 октября. Я уже трижды обжегся на обещаниях высокой активности и регулярных постов.
С нового года я постараюсь начать прорабатывать нормальный контент план и делиться с вами чаще полезными и крутыми постами про рынок, положение дел и прочей информацией для того что мои подписчики качались во всех направлениях.
А пока что нужно ваша помощь.
Нашей менторской программе год и мы решили что уже доросли до собственного мерча.
Он будет разыгран среди наших студентов, а от вас требуется помочь выбрать 7 победителей. Ниже будут выложены примеры работ и голосовалка.
Запрос был простой:
Нужна "лайв" фотка \ видео, где бы был текст Frontend Alliance. Допускалась постобработка в ИИ.
p.s. Кстати, за дизайн отдельный лайк крутой @exxares. Нужен крутой дизайн мерча, сайта, да и вообще чего угодно — обращайтесь.
Полезное:
🎞 YouTube |🚀Менторство |🎓Roadmap
С нового года я постараюсь начать прорабатывать нормальный контент план и делиться с вами чаще полезными и крутыми постами про рынок, положение дел и прочей информацией для того что мои подписчики качались во всех направлениях.
А пока что нужно ваша помощь.
Нашей менторской программе год и мы решили что уже доросли до собственного мерча.
Он будет разыгран среди наших студентов, а от вас требуется помочь выбрать 7 победителей. Ниже будут выложены примеры работ и голосовалка.
Запрос был простой:
Нужна "лайв" фотка \ видео, где бы был текст Frontend Alliance. Допускалась постобработка в ИИ.
p.s. Кстати, за дизайн отдельный лайк крутой @exxares. Нужен крутой дизайн мерча, сайта, да и вообще чего угодно — обращайтесь.
Полезное:
Please open Telegram to view this post
VIEW IN TELEGRAM
6🔥7❤3🤝2👍1
Forwarded from Путь к CEO (18+) | Борцов Дмитрий
2🔥7❤3👍3
Forwarded from Путь к CEO (18+) | Борцов Дмитрий
Кто достоин мерча?
Final Results
23%
Качок в майке
2%
ПП овощи на столе
7%
Автобус на внимательность
6%
Парень с указкой
4%
FA на окне
5%
FA на чашке кофе
18%
Спящий мужчина с фонарём
7%
В чем сила, брат?
16%
Ёлочка
33%
Лежащий мужчина на снегу
2🔥9👍2❤1
Итоги 2025 года
Друзья, всех с наступающим Новым годом! 🎄
Этот год вышел очень насыщенным на работу и активности. Хочу закрепить основные.
— Сообщество Frontend Alliance практически дошло до 200 участников.
Это безумно мотивирует. Особенно радует, когда ребята разбираются в новом материале, растут и получают офферы.
Мы, в свою очередь, постоянно улучшаем программу и добавляем новые активности.
— Запустили свой сайт.
— Сделали бесплатный frontend роудмап.
— Запустили YouTube.
К сожалению, на него совсем не было времени и сил. Это точно один из ключевых векторов развития на следующий год.
— Даже успели запустить свой первый мерч!)
— Начали активную работу над внутренним продуктом для менторства.
В следующем году я уже точно смогу его показать и подробно рассказать.
— Сделал предложение своей возлюбленной 💍
И ещё успел побывать на свадьбе Димы (вдохновился).
— Записал два технических курса (не на свой канал), которые выйдут примерно в феврале–марте следующего года. По System Design и TypeScript.
В следующем году хочу еще больше прокачаться в этом ремесле.
— Начал ходить в зал и целый год стабильно его посещал.
Одно из лучших решений года: набрал 12 кг, почти пожал сотку, чувствую себя прекрасно.
— Этот канал практически дорос до 1к подписчиков, чему я безумно рад.
Следующий год обещает быть не менее насыщенным и продуктивным.
Спасибо, что читаете и поддерживаете!
🎄 С наступающим новым годом!
Искренне желаю, чтобы 2026 стал стартом чего-то большего в вашей жизни!
✈️ Telegram | 🎓 Менторство | 📹 YouTube | 👩💻 Roadmap
Друзья, всех с наступающим Новым годом! 🎄
Этот год вышел очень насыщенным на работу и активности. Хочу закрепить основные.
— Сообщество Frontend Alliance практически дошло до 200 участников.
Это безумно мотивирует. Особенно радует, когда ребята разбираются в новом материале, растут и получают офферы.
Мы, в свою очередь, постоянно улучшаем программу и добавляем новые активности.
— Запустили свой сайт.
— Сделали бесплатный frontend роудмап.
— Запустили YouTube.
К сожалению, на него совсем не было времени и сил. Это точно один из ключевых векторов развития на следующий год.
— Даже успели запустить свой первый мерч!)
— Начали активную работу над внутренним продуктом для менторства.
В следующем году я уже точно смогу его показать и подробно рассказать.
— Сделал предложение своей возлюбленной 💍
И ещё успел побывать на свадьбе Димы (вдохновился).
— Записал два технических курса (не на свой канал), которые выйдут примерно в феврале–марте следующего года. По System Design и TypeScript.
В следующем году хочу еще больше прокачаться в этом ремесле.
— Начал ходить в зал и целый год стабильно его посещал.
Одно из лучших решений года: набрал 12 кг, почти пожал сотку, чувствую себя прекрасно.
— Этот канал практически дорос до 1к подписчиков, чему я безумно рад.
Следующий год обещает быть не менее насыщенным и продуктивным.
Спасибо, что читаете и поддерживаете!
Искренне желаю, чтобы 2026 стал стартом чего-то большего в вашей жизни!
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥25❤13🎉10👍2🥰1
Разница между type и interface в TypeScript
В TS есть два способа описать структуру данных - type и interface.
На первый взгляд они похожи: оба позволяют объявлять объекты, описывать сигнатуры функций и имплементацию классов.
Но есть важные отличия, которые стоит понимать.
В современном TS типы и интерфейсы практически взаимозаменяемые. Но тип может использоваться для примитивов, а интерфейс нет (всегда объектный тип).
В простых случаях интерфейс и тип почти одно и то же (скрин 1).
И TUser, и IUser описывают одинаковую структуру объекта.
Чтобы объединить несколько типов: для интерфейсов используется extends, а для типов - пересечение (&).
При этом TypeScript рекомендует использовать интерфейсы. Почему так?
Есть несколько причин.
1️⃣ Производительность и проверки типов:
TypeScript кэширует отношение интерфейсов внутри компилятора, что делает компиляцию более эффективной.
А вот пересечения типов каждый раз пересчитываются заново.
Из-за этого скорость проверки типов выше, особенно в больших и сложных типах.
2️⃣ Как TypeScript проверяет совместимость.
Когда мы сравниваем объект с типом A & B - TS сначала проверяет совместимость с A, потом с B
При interface extends - TS работает с единым структурным описанием типа.
3️⃣ Отсюда третий момент - ошибки.
У интерфейсов ошибки обычно короче и понятнее: TS сразу показывает все конфликтующие поля.
Через type - вычисляет пошагово и сначала сообщит, что не хватает одного ключа, а уже потом другого.
В примере (скрин 2) ошибка при использования type, говорит, что отсутствует поле agе, но не говорит про поле address, которое тоже отсутствует.
4️⃣ Интерфейсы поддерживают объединение объявлений (declaration merging).
Если объявить интерфейс с тем же именем, что и уже существующий, TS объединит их свойства.
Это может показаться небезопасным.
Однако у этого есть важный плюс: часто необходимо расширять уже существующие интерфейсы, например:
- Добавлять новые свойства к браузерным событиям.
- Расширять глобальные объекты, например Window, если внешняя SDK добавляет на него свой инстанс класса (скрин 3).
В таких случаях declaration merging позволяет TS понимать новые свойства и типизация при этом остается корректной. С type так делать нельзя.
Я в проектах предпочитаю везде использовать интерфейсы, а типы только для примитивов.
✈️ Telegram | 🎓 Менторство | 📹 YouTube | 👩💻 Roadmap
В TS есть два способа описать структуру данных - type и interface.
На первый взгляд они похожи: оба позволяют объявлять объекты, описывать сигнатуры функций и имплементацию классов.
Но есть важные отличия, которые стоит понимать.
В современном TS типы и интерфейсы практически взаимозаменяемые. Но тип может использоваться для примитивов, а интерфейс нет (всегда объектный тип).
В простых случаях интерфейс и тип почти одно и то же (скрин 1).
И TUser, и IUser описывают одинаковую структуру объекта.
Чтобы объединить несколько типов: для интерфейсов используется extends, а для типов - пересечение (&).
При этом TypeScript рекомендует использовать интерфейсы. Почему так?
Есть несколько причин.
TypeScript кэширует отношение интерфейсов внутри компилятора, что делает компиляцию более эффективной.
А вот пересечения типов каждый раз пересчитываются заново.
Из-за этого скорость проверки типов выше, особенно в больших и сложных типах.
Когда мы сравниваем объект с типом A & B - TS сначала проверяет совместимость с A, потом с B
При interface extends - TS работает с единым структурным описанием типа.
У интерфейсов ошибки обычно короче и понятнее: TS сразу показывает все конфликтующие поля.
Через type - вычисляет пошагово и сначала сообщит, что не хватает одного ключа, а уже потом другого.
В примере (скрин 2) ошибка при использования type, говорит, что отсутствует поле agе, но не говорит про поле address, которое тоже отсутствует.
Если объявить интерфейс с тем же именем, что и уже существующий, TS объединит их свойства.
Это может показаться небезопасным.
Однако у этого есть важный плюс: часто необходимо расширять уже существующие интерфейсы, например:
- Добавлять новые свойства к браузерным событиям.
- Расширять глобальные объекты, например Window, если внешняя SDK добавляет на него свой инстанс класса (скрин 3).
В таких случаях declaration merging позволяет TS понимать новые свойства и типизация при этом остается корректной. С type так делать нельзя.
Я в проектах предпочитаю везде использовать интерфейсы, а типы только для примитивов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥28👍9✍7❤5😁1🤣1
Статическая и динамическая типизация
В JavaScript есть типы. Существует 8 типов данных.
Но при этом JS имеет динамическую и неявную типизацию.
🟣 Динамическая означает, что тип переменной определяется не при ее объявлении, а во время выполнения программы в момент присваивания значения и может меняться динамически.
🟣 Неявная говорит о том, что тип выводится автоматически без явного указания.
В данной строке javascript автоматически определит, что в переменной x лежит строка.
TypeScript также поддерживает неявный вывод типов, который помогает упростить код.
Однако не всегда можно полностью полагаться на него - в некоторых случаях компилятор не сможет однозначно определить тип.
При необходимости в TypeScript можно явно указать тип для переменных, чтобы повысить читаемость и надежность кода:
🟣 TypeScript является надстройкой над JavaScript и добавляет статическую типизацию.
Это означает, что тип переменной определяется на этапе компиляции кода, что позволяет получать мощные подсказки от IDE и выявлять ошибки на этапе написания кода.
То есть код анализируется не запускаясь.
🟣 Это круто, но при этом имеет свои ограничения, например, при работе с данными в райнтайме.
Если мы делаем fetch-запрос к бэкенду и ожидаем данные определённого типа - TS вынужден «доверять» разработчикам, потому что не сможет проверить этот тип во время выполнения.
Посмотрим на примере следующего кода. У нас есть тип Mentor и функция fetchMentor, когда получает данные с бекенда по айди ментора.
Но допустим, в какой-то момент, бекенд изменил контракт и данные пришли не те, которые мы ожидали. TypeScript этого не знает, потому что функция fetchMentor обещала, что результат будет типа Mentor.
🟣 Когда мы видим запись вида:
мы думаем, что в переменной x лежит число, но это не до конца верно.
Эта запись означает, что мы верим, что там лежит число, но формально этого может не быть.
На этапе статического анализа мы не можем гарантировать, что после fetch'a и LS'a данные будут определенного типа.
О том как себя обезопасить в рантайме - будет в отдельном посте.
✈️ Telegram | 🎓 Менторство | 📹 YouTube | 👩💻 Roadmap
В JavaScript есть типы. Существует 8 типов данных.
Но при этом JS имеет динамическую и неявную типизацию.
let value = 42; // Тип: number
console.log(typeof value); // "number"
value = "текст"; // Тип изменился во время выполнения
console.log(typeof value); // "string"
value = true; // Тип снова изменился
console.log(typeof value); // "boolean"
let x = 'hello world!'
console.log(typeof x); // "string"
В данной строке javascript автоматически определит, что в переменной x лежит строка.
TypeScript также поддерживает неявный вывод типов, который помогает упростить код.
Однако не всегда можно полностью полагаться на него - в некоторых случаях компилятор не сможет однозначно определить тип.
При необходимости в TypeScript можно явно указать тип для переменных, чтобы повысить читаемость и надежность кода:
let x: string = 'hello world!'
Это означает, что тип переменной определяется на этапе компиляции кода, что позволяет получать мощные подсказки от IDE и выявлять ошибки на этапе написания кода.
То есть код анализируется не запускаясь.
Если мы делаем fetch-запрос к бэкенду и ожидаем данные определённого типа - TS вынужден «доверять» разработчикам, потому что не сможет проверить этот тип во время выполнения.
Посмотрим на примере следующего кода. У нас есть тип Mentor и функция fetchMentor, когда получает данные с бекенда по айди ментора.
Но допустим, в какой-то момент, бекенд изменил контракт и данные пришли не те, которые мы ожидали. TypeScript этого не знает, потому что функция fetchMentor обещала, что результат будет типа Mentor.
type Mentor = {
id: string;
name: string;
email: string;
};
async function fetchMentor(id: number): Promise<Mentor> {
const res = await fetch(`/api/mentors/${id}`);
return await res.json(); // ← TypeScript верит, что это тип Mentor
}
const mentor = await fetchMentor(1);
// А с сервера пришло { "id": 1, "fullname": "Frontend Alliance" }
console.log(mentor.name.toUpperCase()); // Упали в рантайме, так как нет поля nameTypeScript проверяет типы только во время компиляции, а не в рантайме.
Тоже самое касается например парсинга localStorage - мы не можем в райтайме проверить, что там в действительности будет.
const x: number = JSON.parse(localStorage.getItem('my-favorite-number') || '');const x: number
мы думаем, что в переменной x лежит число, но это не до конца верно.
Эта запись означает, что мы верим, что там лежит число, но формально этого может не быть.
На этапе статического анализа мы не можем гарантировать, что после fetch'a и LS'a данные будут определенного типа.
О том как себя обезопасить в рантайме - будет в отдельном посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍15🔥14✍6❤1
Структурная и номинальная типизация
🟣 Номинальная типизация (nominal typing) - это когда совместимость типов определяется по их имени или идентификаторам, а не по внутренней структуре.
Даже если структура одинаковая - типы разные.
Два типа считаются совместимыми, только если они явно связаны иерархией.
Это более строгий и безопасный, но менее гибкий подход по сравнению со структурной типизацией, характерный для языков типа Java и C#.
Рассмотрим пример кода на Java (скрин 1).
У нас есть класс User и класс Admin. И если мы попытаемся создать переменную user типа User и присвоить в нее инстанс класса Admin, то будет ошибка, потому что в джаве номинальная типизация и фактически эти типы разные.
🟣 Структурная типизация (structural typing) - это система проверки типов, где совместимость определяется не по имени, а по внутренней структуре.
TypeScript как раз использует структурную типизацию, то есть:
Совместимость типов определяется по структуре - если объект имеет все требуемые свойства и методы, он считается совместимым, независимо от имени типа.
Тот же самый пример (скрин 2).
TypeScript разрешает это присваивание, потому что у обоих типов одна и та же структура (свойство name типа string).
🟣 Но мы можем заставить типы в классах вести себя как номинальные, для это нужно добавить приватное поле (скрин 3).
Когда мы объявляем поле с ключевым словом private, то TS применяет ограничение на уровне компиляции. Это означает, что приватное поле может быть доступно только внутри того же класса.
Поэтому два класса, которые имеют приватные поля с одинаковыми именами - структурно несовместимы, так как тайпскрипт будет учитывать "происхождение" приватных полей.
При необходимости номинальное поведение так же можно симулировать через брендирование (расскажу в отдельном посте).
🟣 Структурная типизация хоть и считается "гибкой", но может привести к неожиданным проблемам. Рассмотрим следующий пример (скрин 4):
У нас есть тип DatabaseConfig, который имеет обязательное поле url и необязательное поля retries. И тип APIConfig, который также имеет обязательное поле url и необязательно поле timeout.
Есть функция startApi, которая принимает конфиг, который должен быть типа APIConfig.
Но из-за структурной типизации мы можем передать внутрь функции переменную, которая имеет другой тип, так как их структура типов совпала.
ТС это разрешил, но в реальности внутри функции мы не сможем обращаться к полю retries - будет ошибка.
В реальности подобные проблемы можно ловить через сотни строчек кода и десятки файлов. Поэтому я считаю, что наличие структурной типизации в ТС - это большое допущение, которое приходится фиксить дополнительными танцами с бубном ради безопасной системы типов.
✈️ Telegram | 🎓 Менторство | 📹 YouTube | 👩💻 Roadmap
Даже если структура одинаковая - типы разные.
Два типа считаются совместимыми, только если они явно связаны иерархией.
Это более строгий и безопасный, но менее гибкий подход по сравнению со структурной типизацией, характерный для языков типа Java и C#.
Рассмотрим пример кода на Java (скрин 1).
У нас есть класс User и класс Admin. И если мы попытаемся создать переменную user типа User и присвоить в нее инстанс класса Admin, то будет ошибка, потому что в джаве номинальная типизация и фактически эти типы разные.
TypeScript как раз использует структурную типизацию, то есть:
Совместимость типов определяется по структуре - если объект имеет все требуемые свойства и методы, он считается совместимым, независимо от имени типа.
Тот же самый пример (скрин 2).
TypeScript разрешает это присваивание, потому что у обоих типов одна и та же структура (свойство name типа string).
Когда мы объявляем поле с ключевым словом private, то TS применяет ограничение на уровне компиляции. Это означает, что приватное поле может быть доступно только внутри того же класса.
Поэтому два класса, которые имеют приватные поля с одинаковыми именами - структурно несовместимы, так как тайпскрипт будет учитывать "происхождение" приватных полей.
При необходимости номинальное поведение так же можно симулировать через брендирование (расскажу в отдельном посте).
У нас есть тип DatabaseConfig, который имеет обязательное поле url и необязательное поля retries. И тип APIConfig, который также имеет обязательное поле url и необязательно поле timeout.
Есть функция startApi, которая принимает конфиг, который должен быть типа APIConfig.
Но из-за структурной типизации мы можем передать внутрь функции переменную, которая имеет другой тип, так как их структура типов совпала.
ТС это разрешил, но в реальности внутри функции мы не сможем обращаться к полю retries - будет ошибка.
В реальности подобные проблемы можно ловить через сотни строчек кода и десятки файлов. Поэтому я считаю, что наличие структурной типизации в ТС - это большое допущение, которое приходится фиксить дополнительными танцами с бубном ради безопасной системы типов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍8✍7❤3