Forwarded from Senior Frontend - javascript, html, css
GraphQL или REST: Какой API выбрать, чтобы не прогадать?
Расскажу о GraphQL, сравню с REST. Разберемся в плюсах и минусах каждого подхода к проектированию API. Выбираем лучший для вашего проекта!
Распространенность и интеграция
В 2015 году Facebook представил GraphQL. С тех пор эта технология набирает популярность, но REST остается лидером. По данным Postman на 2024 год, GraphQL используют 29% разработчиков, REST — 90%.
Если заранее неизвестны потребители API, лучше выбрать REST — он проще и популярнее:
- Разработчикам, знакомым с HTTP, легко освоить REST. Он использует стандартные HTTP-методы и принципы.
- REST API можно реализовать на любом языке, поддерживающем HTTP, без дополнительных слоев.
- REST — проверенная технология с сильным сообществом и множеством готовых инструментов.
Получение данных
GraphQL позволяет клиентам запрашивать только нужные данные, избегая избыточного или недостаточного получения. Это повышает эффективность сетевых запросов: передаются только необходимые данные.
Рассмотрим пример. Есть сущность «Игрушка» (Toy), которую создает «Мастер» (Master), привязанный к «Пользователю» (User). У игрушки также есть «Категория» (Category) и «Теги» (Tags).
GraphQL позволяет получить все данные одним запросом:
В случае REST API потребовалась бы серия запросов:
В приложениях со сложными связями между доменами GraphQL упрощает получение данных: один запрос вместо пяти (в примере). Кроме того, можно исключить ненужные поля, например, createdAt и updatedAt. GraphQL возвращает только то, что нужно.
Версионирование
GraphQL использует одну версию endpoint. Изменения вносятся в схему без явного версионирования API, что упрощает развитие.
REST API нужно версионировать для безопасных изменений. Обычно это делается в URL, например: http://localhost:8080/v1/toys.
Ошибки и коды ответа
GraphQL всегда отвечает кодом 200 OK, даже при ошибках. Информацию об ошибке ищите в поле errors JSON-ответа. Клиент не может проверить статус по HTTP-коду и вынужден анализировать тело ответа.
REST использует стандартные HTTP-коды (400, 404, 500) для обозначения результата. Это делает обработку ошибок в REST более наглядной
Заключение
Выбор между GraphQL и REST — это вопрос потребностей проекта. REST лидирует благодаря простоте, популярности и развитым инструментам. GraphQL же гибче в запросах: запрашиваем только нужное, не перегружаем сеть лишним, что важно для сложных приложений.
Тестировать GraphQL сложнее, особенно с файлами: больше настроек в запросах, чем в REST. GraphQL проще версионировать — меняем схему, и всё, а в REST приходится менять URL. Наконец, GraphQL всегда отвечает кодом 200 и сообщает об ошибках в теле ответа, а REST использует стандартные коды ошибок, что делает их более заметными.
👉 @seniorFront
Расскажу о GraphQL, сравню с REST. Разберемся в плюсах и минусах каждого подхода к проектированию API. Выбираем лучший для вашего проекта!
Распространенность и интеграция
В 2015 году Facebook представил GraphQL. С тех пор эта технология набирает популярность, но REST остается лидером. По данным Postman на 2024 год, GraphQL используют 29% разработчиков, REST — 90%.
Если заранее неизвестны потребители API, лучше выбрать REST — он проще и популярнее:
- Разработчикам, знакомым с HTTP, легко освоить REST. Он использует стандартные HTTP-методы и принципы.
- REST API можно реализовать на любом языке, поддерживающем HTTP, без дополнительных слоев.
- REST — проверенная технология с сильным сообществом и множеством готовых инструментов.
Получение данных
GraphQL позволяет клиентам запрашивать только нужные данные, избегая избыточного или недостаточного получения. Это повышает эффективность сетевых запросов: передаются только необходимые данные.
Рассмотрим пример. Есть сущность «Игрушка» (Toy), которую создает «Мастер» (Master), привязанный к «Пользователю» (User). У игрушки также есть «Категория» (Category) и «Теги» (Tags).
GraphQL позволяет получить все данные одним запросом:
query getToy {
toy(id: 1) {
id
name
category {
id
name
}
tags {
id
name
}
master {
id
info
}
}
}В случае REST API потребовалась бы серия запросов:
GET http://localhost:8080/toys/1 - Получаем игрушку по ID
GET http://localhost:8080/categories/2 - Получаем категорию игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/tags?id=1&id=2&id=3 - Получаем теги игрушки по ID, которые взяли из объекта игрушки
GET http://localhost:8080/masters/3 - Получаем мастера игрушки по ID, который взяли из объекта игрушки
GET http://localhost:8080/users/4 - Получаем пользователя, к которому привязан мастер, по ID, который взяли из объекта мастера
В приложениях со сложными связями между доменами GraphQL упрощает получение данных: один запрос вместо пяти (в примере). Кроме того, можно исключить ненужные поля, например, createdAt и updatedAt. GraphQL возвращает только то, что нужно.
Версионирование
GraphQL использует одну версию endpoint. Изменения вносятся в схему без явного версионирования API, что упрощает развитие.
REST API нужно версионировать для безопасных изменений. Обычно это делается в URL, например: http://localhost:8080/v1/toys.
Ошибки и коды ответа
GraphQL всегда отвечает кодом 200 OK, даже при ошибках. Информацию об ошибке ищите в поле errors JSON-ответа. Клиент не может проверить статус по HTTP-коду и вынужден анализировать тело ответа.
REST использует стандартные HTTP-коды (400, 404, 500) для обозначения результата. Это делает обработку ошибок в REST более наглядной
Заключение
Выбор между GraphQL и REST — это вопрос потребностей проекта. REST лидирует благодаря простоте, популярности и развитым инструментам. GraphQL же гибче в запросах: запрашиваем только нужное, не перегружаем сеть лишним, что важно для сложных приложений.
Тестировать GraphQL сложнее, особенно с файлами: больше настроек в запросах, чем в REST. GraphQL проще версионировать — меняем схему, и всё, а в REST приходится менять URL. Наконец, GraphQL всегда отвечает кодом 200 и сообщает об ошибках в теле ответа, а REST использует стандартные коды ошибок, что делает их более заметными.
👉 @seniorFront
– OpenAI представила новый голосовой ассистент, который теперь может в реальном времени анализировать изображение, речь и текст — конкуренция Siri и Alexa становится серьезной.
– Google тестирует поиск с интеграцией ИИ-резюме, который меняет привычный способ продвижения сайтов. SEO-специалисты — держитесь!
– TikTok анонсировал AI Creative Assistant — теперь ИИ помогает создавать и тестировать рекламные креативы за секунды.
Хочешь быть в курсе последних новостей в мире ИИ/ИТ/маркетинга ?
Мы собрали папку Telegram-каналов, где эксперты каждый день:
https://t.me/addlist/gs3Io1EOk2lhNmEy
✔ разбирают тренды
✔ выкладывают кейсы
✔ делятся фреймворками, которые экономят десятки часов
✔ и сразу показывают, как использовать ИИ в маркетинге и ИТ на практике.
📂 Открой доступ к Telegram-папке → https://t.me/addlist/gs3Io1EOk2lhNmEy
Original post link: t.me/frontendnoteschannel/4625
Forwarded and filtered by @smartfeed_bot
– Google тестирует поиск с интеграцией ИИ-резюме, который меняет привычный способ продвижения сайтов. SEO-специалисты — держитесь!
– TikTok анонсировал AI Creative Assistant — теперь ИИ помогает создавать и тестировать рекламные креативы за секунды.
Хочешь быть в курсе последних новостей в мире ИИ/ИТ/маркетинга ?
Мы собрали папку Telegram-каналов, где эксперты каждый день:
https://t.me/addlist/gs3Io1EOk2lhNmEy
✔ разбирают тренды
✔ выкладывают кейсы
✔ делятся фреймворками, которые экономят десятки часов
✔ и сразу показывают, как использовать ИИ в маркетинге и ИТ на практике.
📂 Открой доступ к Telegram-папке → https://t.me/addlist/gs3Io1EOk2lhNmEy
Original post link: t.me/frontendnoteschannel/4625
Forwarded and filtered by @smartfeed_bot
Forwarded from Веб-страница
Стрелочные и обычные функции в JavaScript: в чём разница?
В JavaScript функции — это основа работы с кодом, и их можно писать разными способами: с помощью обычных и стрелочных функций. На первый взгляд, они решают одну задачу — выполняют код, — но различия между ними влияют на то, как и где их лучше применять.
Давайте разберёмся, в чём заключаются эти различия, посмотрим на пример и выясним, когда какую функцию стоит использовать.
Обычные функции пишутся с использованием ключевого слова
This. Одно из главных различий — как функции работают с контекстом
— В обычной функции
— В стрелочной функции
Это важно, когда вы работаете с объектами или обработчиками событий.
Аргументы. Обычные функции имеют встроенный объект
Конструкторы. Обычную функцию можно использовать с
Генераторы. Обычные функции поддерживают синтаксис
Чтобы понять разницу работы с
— В методе
— В методе
Этот пример показывает, почему выбор типа функции важен в зависимости от задачи.
Стрелочные функции отлично подходят для коротких коллбэков (например, в
Обычные функции нужно использовать в методах объектов, где важен динамический
Стрелочные и обычные функции в JavaScript — это инструменты с разными сильными сторонами. Понимание их различий поможет вам выбрать правильный подход для каждой ситуации.
#простымисловами #javascript
В JavaScript функции — это основа работы с кодом, и их можно писать разными способами: с помощью обычных и стрелочных функций. На первый взгляд, они решают одну задачу — выполняют код, — но различия между ними влияют на то, как и где их лучше применять.
Давайте разберёмся, в чём заключаются эти различия, посмотрим на пример и выясним, когда какую функцию стоит использовать.
Обычные функции пишутся с использованием ключевого слова
function, а стрелочные — с помощью более компактного синтаксиса =>.//Обычная функция
function greet(name) {
return "Привет, " + name;
}
//Стрелочная функция
const greet = (name) => "Привет, " + name;
This. Одно из главных различий — как функции работают с контекстом
this.— В обычной функции
this зависит от того, как её вызвали.— В стрелочной функции
this берётся из внешнего окружения и не меняется.Это важно, когда вы работаете с объектами или обработчиками событий.
Аргументы. Обычные функции имеют встроенный объект
arguments для доступа ко всем переданным параметрам, а стрелочные — нет (но можно использовать ...args).Конструкторы. Обычную функцию можно использовать с
new для создания объектов, стрелочную — нельзя.Генераторы. Обычные функции поддерживают синтаксис
function* для генераторов, стрелочные — нет.Чтобы понять разницу работы с
this на практике, рассмотрим пример с объектом:const person = {
name: "Алекс",
sayHello: function() {
console.log("Привет, я " + this.name);
},
sayHelloArrow: () => {
console.log("Привет, я " + this.name);
}
};
person.sayHello(); // Привет, я Алекс
person.sayHelloArrow(); // Привет, я undefined— В методе
sayHello (обычная функция) this указывает на объект person, и мы получаем доступ к свойству name.— В методе
sayHelloArrow (стрелочная функция) this берётся из внешнего контекста (например, window), где name не определён, поэтому результат — undefined.Этот пример показывает, почему выбор типа функции важен в зависимости от задачи.
Стрелочные функции отлично подходят для коротких коллбэков (например, в
map или setTimeout) и случаев, когда не нужен собственный`this`.Обычные функции нужно использовать в методах объектов, где важен динамический
this, или когда нужны конструкторы и объект arguments.Стрелочные и обычные функции в JavaScript — это инструменты с разными сильными сторонами. Понимание их различий поможет вам выбрать правильный подход для каждой ситуации.
#простымисловами #javascript
Forwarded from Senior Frontend - javascript, html, css
Зачем нужен Nginx?
Nginx — это мощный веб-сервер, который используется для раздачи статических файлов, балансировки нагрузки, проксирования запросов и обеспечения безопасности.
Как Nginx раздаёт фронтенд-приложение?
Когда мы билдим SPA-приложение (например, React/Vue/Angular), в папке
Как Nginx проксирует запросы к бэкенду?
Если фронтенд (
Как Nginx балансирует нагрузку?
Если у нас несколько бэкенд-серверов, Nginx может распределять нагрузку между ними.
Как Nginx ускоряет сайт с кэшем?
Кэширование уменьшает нагрузку на сервер и ускоряет загрузку страниц.
👉 @seniorFront
Nginx — это мощный веб-сервер, который используется для раздачи статических файлов, балансировки нагрузки, проксирования запросов и обеспечения безопасности.
Как Nginx раздаёт фронтенд-приложение?
Когда мы билдим SPA-приложение (например, React/Vue/Angular), в папке
dist появляются статические файлы (index.html, app.js, styles.css). server {
listen 80;
server_name myapp.com;
root /var/www/myapp/dist;
index index.html;
location / {
try_files $uri /index.html;
}
}Как Nginx проксирует запросы к бэкенду?
Если фронтенд (
myapp.com) и бэкенд (api.myapp.com) находятся на разных серверах, Nginx может перенаправлять запросы на API. server {
listen 80;
server_name myapp.com;
root /var/www/myapp/dist;
index index.html;
location / {
try_files $uri /index.html;
}
# Проксирование API-запросов
location /api/ {
proxy_pass http://localhost:5000/; # Node.js, Python, PHP и т. д.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Как Nginx балансирует нагрузку?
Если у нас несколько бэкенд-серверов, Nginx может распределять нагрузку между ними.
upstream backend {
server backend1.myapp.com;
server backend2.myapp.com;
}
server {
listen 80;
server_name api.myapp.com;
location / {
proxy_pass http://backend;
}
}Как Nginx ускоряет сайт с кэшем?
Кэширование уменьшает нагрузку на сервер и ускоряет загрузку страниц.
location /static/ {
expires 7d; # Кэшировать файлы на 7 дней
add_header Cache-Control "public, max-age=604800";
}👉 @seniorFront
Forwarded from Senior Frontend - javascript, html, css
Гореть, но не сгорать: практические советы по борьбе с burnout’ом
Важно понять: выгорание — это не ваш личный факап или ошибка. Это сигнал всей системы — целого организма — что что-то идет не так. Бороться с выгоранием через «затыкание дыр» не выйдет. Если вы наконец-то полноценно отдохнете в эту субботу и даже воскресенье, а потом вернетесь к привычному режиму, проблема никуда не уйдет. И если ее игнорировать, тоже.
Что на самом деле нужно делать?
Только системный подход, только хардкор — смена личных и рабочих привычек, выстраивание нового подхода к рабочему процессу. Ниже — несколько советов.
Отказываемся от перфекционизма
Перфекционизм в ИТ не только бесполезен, но даже опасен. Код не обязан быть идеальным с первой попытки, а технический долг — это нормальная история. Можно попробовать упражнение «достаточно хорошо»: установить четкие критерии завершения задачи и не позволять себе бесконечно её улучшать. Никаких больше «Нет предела совершенству».
Меняем отношение к ошибкам и достижениям
Теперь баг — это не не доказательство некомпетентности, а часть нормального рабочего процесса. Параллельно с этим переводим фокус на позитив. Можно отдельно записывать собственные достижения, например, решенные задачи, положительный фидбек от коллег или пользователей. Перечитываем, когда накатывает.
Беремся за физическое восстановление
Здоровье у вас одно, стимуляторы из Fallout у нас пока не изобрели, а бионические протезы не так доступны, как в Cyberpunk 2077. Поэтому беремся за восстановление организма. Учимся замечать усталость. В глазах рябит от кода, в голове туман — идем отдыхать, а не терпим. Можно попробовать внедрить правило 90/30 (30-минутный отдых каждые полчаса) или другой формат перерывов. Естественно, во время отдыха не скроллим ленты и стараемся вообще не смотреть в экран. Обедаем где-нибудь вдали от клавиатуры, если на удаленке — тем более.
Если новые привычки внедрять сложно, делаем это постепенно. Например, сначала учимся по-настоящему уходить на перерыв от работы. Потом отказываемся от гаджетов во время отдыха.
Главное — помните. К этому состоянию вы пришли не за один месяц, а значит, восстановление тоже займет какое-то время. Не ждите, что после недельки в новом режиме или отпуска сразу все наладится.
👉 @seniorFront
Важно понять: выгорание — это не ваш личный факап или ошибка. Это сигнал всей системы — целого организма — что что-то идет не так. Бороться с выгоранием через «затыкание дыр» не выйдет. Если вы наконец-то полноценно отдохнете в эту субботу и даже воскресенье, а потом вернетесь к привычному режиму, проблема никуда не уйдет. И если ее игнорировать, тоже.
Что на самом деле нужно делать?
Только системный подход, только хардкор — смена личных и рабочих привычек, выстраивание нового подхода к рабочему процессу. Ниже — несколько советов.
Отказываемся от перфекционизма
Перфекционизм в ИТ не только бесполезен, но даже опасен. Код не обязан быть идеальным с первой попытки, а технический долг — это нормальная история. Можно попробовать упражнение «достаточно хорошо»: установить четкие критерии завершения задачи и не позволять себе бесконечно её улучшать. Никаких больше «Нет предела совершенству».
Меняем отношение к ошибкам и достижениям
Теперь баг — это не не доказательство некомпетентности, а часть нормального рабочего процесса. Параллельно с этим переводим фокус на позитив. Можно отдельно записывать собственные достижения, например, решенные задачи, положительный фидбек от коллег или пользователей. Перечитываем, когда накатывает.
Беремся за физическое восстановление
Здоровье у вас одно, стимуляторы из Fallout у нас пока не изобрели, а бионические протезы не так доступны, как в Cyberpunk 2077. Поэтому беремся за восстановление организма. Учимся замечать усталость. В глазах рябит от кода, в голове туман — идем отдыхать, а не терпим. Можно попробовать внедрить правило 90/30 (30-минутный отдых каждые полчаса) или другой формат перерывов. Естественно, во время отдыха не скроллим ленты и стараемся вообще не смотреть в экран. Обедаем где-нибудь вдали от клавиатуры, если на удаленке — тем более.
Если новые привычки внедрять сложно, делаем это постепенно. Например, сначала учимся по-настоящему уходить на перерыв от работы. Потом отказываемся от гаджетов во время отдыха.
Главное — помните. К этому состоянию вы пришли не за один месяц, а значит, восстановление тоже займет какое-то время. Не ждите, что после недельки в новом режиме или отпуска сразу все наладится.
👉 @seniorFront
Forwarded from Frontender's notes [ru]
AbortController в JavaScript и зачем он используется?AbortController — это API, который позволяет отменять асинхронные операции, такие как запросы fetch. Это полезно для предотвращения утечек ресурсов и отмены операций, которые больше не нужны.const controller = new AbortController();
const signal = controller.signal;
// Отправляем запрос с возможностью отмены
fetch('https://jsonplaceholder.typicode.com/posts', { signal })
.then(response => response.json())
.then(data => console.log(data))
.catch(err => {
if (err.name === 'AbortError') {
console.log('Запрос был отменён');
} else {
console.error(err);
}
});
// Отмена запроса через 500 мс
setTimeout(() => controller.abort(), 500);
🗣️ В этом примере AbortController отменяет запрос через 500 мс. Это позволяет избежать обработки ненужных данных, если, например, пользователь покинул страницу или отменил действие.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Senior Frontend Developer | JavaScript, React, HTML & CSS
Оптимизация производительности веб-приложений с помощью Lighthouse
Цель этой темы - показать, как использовать инструмент Lighthouse от Google для оптимизации производительности веб-приложений. Lighthouse - это автоматизированное средство для проверки качества веб-страниц, которое анализирует различные аспекты производительности и дает рекомендации по их улучшению.
В этом примере мы используем Lighthouse API для запуска аудита производительности веб-приложения. Сначала мы запускаем Chrome в Headless-режиме с помощью
После выполнения аудита мы выводим результаты в консоль. Это включает оценку производительности, оценку лучших практик и оценку доступности. Вы можете использовать эти результаты, чтобы идентифицировать области, требующие оптимизации производительности вашего веб-приложения в соответствии с рекомендациями Lighthouse.
Обратите внимание, что этот пример демонстрирует базовую конфигурацию Lighthouse. Вы также можете настроить его для анализа других аспектов производительности, таких как время загрузки, использование кэша, оптимизация изображений и многое другое.
Цель этой темы - показать, как использовать инструмент Lighthouse от Google для оптимизации производительности веб-приложений. Lighthouse - это автоматизированное средство для проверки качества веб-страниц, которое анализирует различные аспекты производительности и дает рекомендации по их улучшению.
В этом примере мы используем Lighthouse API для запуска аудита производительности веб-приложения. Сначала мы запускаем Chrome в Headless-режиме с помощью
chrome-launcher. Затем мы вызываем функцию lighthouse, передавая URL веб-приложения и необязательный конфигурационный объект.После выполнения аудита мы выводим результаты в консоль. Это включает оценку производительности, оценку лучших практик и оценку доступности. Вы можете использовать эти результаты, чтобы идентифицировать области, требующие оптимизации производительности вашего веб-приложения в соответствии с рекомендациями Lighthouse.
Обратите внимание, что этот пример демонстрирует базовую конфигурацию Lighthouse. Вы также можете настроить его для анализа других аспектов производительности, таких как время загрузки, использование кэша, оптимизация изображений и многое другое.
Forwarded from Senior Frontend Developer | JavaScript, React, HTML & CSS
Разработка адаптивных веб-приложений с помощью Microsoft Blazor
Microsoft Blazor - это фреймворк для создания интерактивных веб-приложений с использованием языка C# и .NET. Одним из ключевых преимуществ Blazor является возможность создания адаптивных приложений, которые автоматически масштабируются и оптимизируются для различных устройств и экранов.
В примере мы создаем простое веб-приложение Blazor счетчика. Оно содержит кнопку, которая увеличивает счетчик при каждом клике. Благодаря адаптивности Blazor, это приложение будет автоматически масштабироваться и корректно отображаться на различных устройствах и экранах.
Blazor использует компонентную модель разработки, где каждый компонент представляет отдельную часть пользовательского интерфейса. Вы можете создавать более сложные компоненты, взаимодействовать с данными и использовать возможности языка C# для разработки функциональности вашего веб-приложения.
Кроме того, Blazor позволяет использовать компоненты как часть существующих веб-приложений, что делает его удобным инструментом для поэтапной миграции или расширения функциональности уже существующих проектов.
Освоение Microsoft Blazor позволит вам создавать адаптивные и интерактивные веб-приложения, используя знакомые инструменты и язык программирования C#.
Microsoft Blazor - это фреймворк для создания интерактивных веб-приложений с использованием языка C# и .NET. Одним из ключевых преимуществ Blazor является возможность создания адаптивных приложений, которые автоматически масштабируются и оптимизируются для различных устройств и экранов.
В примере мы создаем простое веб-приложение Blazor счетчика. Оно содержит кнопку, которая увеличивает счетчик при каждом клике. Благодаря адаптивности Blazor, это приложение будет автоматически масштабироваться и корректно отображаться на различных устройствах и экранах.
Blazor использует компонентную модель разработки, где каждый компонент представляет отдельную часть пользовательского интерфейса. Вы можете создавать более сложные компоненты, взаимодействовать с данными и использовать возможности языка C# для разработки функциональности вашего веб-приложения.
Кроме того, Blazor позволяет использовать компоненты как часть существующих веб-приложений, что делает его удобным инструментом для поэтапной миграции или расширения функциональности уже существующих проектов.
Освоение Microsoft Blazor позволит вам создавать адаптивные и интерактивные веб-приложения, используя знакомые инструменты и язык программирования C#.
Forwarded from Senior Frontend - javascript, html, css
Вайб-кодинг: практика, о которой почему-то не говорят
В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.
Я откидываюсь в кресле, беру наушники и смотрю, как работает LLM. Можно сразу несколько, работающих над разными частями проекта:
Пример проекта с прикручиванием аналитики к инфраструктуре:
- Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
- Попросил превратить это в архитектурный план.
- Отревьюил, поправил тупые ошибки.
- Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
- Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
- Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
- Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
- Написал манифесты для Kubernetes и Docker Compose для локального запуска.
- Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.
И всё.
А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами. Продолжение в статье
👉 @seniorFront
В феврале мир разработки перевернулся с выходом Sonnet 3.7. Потому что вдруг внезапно оказалось, что джуны уже не очень-то и нужны. И нейросетка нормально заменяет мидлов тоже.
Я откидываюсь в кресле, беру наушники и смотрю, как работает LLM. Можно сразу несколько, работающих над разными частями проекта:
Пример проекта с прикручиванием аналитики к инфраструктуре:
- Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
- Попросил превратить это в архитектурный план.
- Отревьюил, поправил тупые ошибки.
- Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
- Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
- Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
- Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
- Написал манифесты для Kubernetes и Docker Compose для локального запуска.
- Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.
И всё.
А теперь практика — что делать с тем, что современные нейросети учились преимущественно на говнокоде и как быть с джунами. Продолжение в статье
👉 @seniorFront
Forwarded from Senior Frontend - javascript, html, css
7 признаков профессиональной стагнации разработчика
В мире кода есть понятие code smells — признаки плохого кода. Сегодня я расскажу о junior smells — характерных признаках «старого джуна». У каждого из них есть яркие черты, по которым их легко распознать. И, что самое важное, — для каждого из этих признаков я подготовил конкретное решение, которое поможет перейти на следующий уровень.
Семь ключевых признаков, по которым можно безошибочно определить, кто действительно вырос, а кто лишь притворяется.
Джун в маске сеньора
Этот тип разработчика внешне уже не выглядит новичком. Он легко оперирует модными терминами, посещает метапы и тренинги, но за технической болтовнёй скрывается отсутствие глубинного понимания. Он может эффектно говорить о полиморфизме, асинхронности и инъекциях зависимостей, но сам не до конца понимает, что стоит за этими словами.
ИИ-зависимость
Когда-то это был синдром «копипасты» со Stack Overflow. Сегодня — новое поколение зависимости: от нейросетей. Всё начинается с удобства — автодополнение, готовые сниппеты, помощь в дебаге. Но со временем инструменты становятся костылём, без которого разработчик чувствует себя беспомощным.
Мастер временных решений
Это один из самых распространённых и опасных признаков старого джуна. В условиях дедлайнов, давления, багов на проде и непрерывного потока задач, он начинает использовать «временные решения» — быстрые костыли, которые якобы потом будут переписаны.
Переусложнитель
Переусложнитель — это не обязательно джун. Это скорее переходная форма: разработчик, обладающий уже неплохими знаниями, но не научившийся правильно дозировать их применение. Он знает архитектурные паттерны, умеет строить сложные системы, но не понимает, когда это уместно, а когда — просто избыточно.
Скоростной гонщик
Это разработчик, который поставил скорость выше всего остального. Быстрее закрытые тикеты, больше строк кода, меньше обсуждений. На первый взгляд — мечта менеджера. Но только до тех пор, пока не наступает фаза изменений. Проблема не в скорости как таковой. Проблема в игнорировании качества. Код гонщика часто не покрыт тестами, написан без оглядки на читаемость и сопровождение, перегружен неочевидной логикой.
Архитектор незаменимости
Этот тип разработчика не просто пишет код — он строит лабиринты. Сложные, запутанные, полные нестандартных решений, нестабильных зависимостей и неписаных правил. Не потому что так надо, а потому что это делает его единственным, кто может с этим разобраться.
Мастер пустых ревью
Самый тихий и коварный из всех. Он не пишет плохой код, не строит сложных систем, не тянет на себе костыли. Он просто не мешает плохому коду попадать в прод. Потому что не делает ревью по-настоящему.
👉 @seniorFront
В мире кода есть понятие code smells — признаки плохого кода. Сегодня я расскажу о junior smells — характерных признаках «старого джуна». У каждого из них есть яркие черты, по которым их легко распознать. И, что самое важное, — для каждого из этих признаков я подготовил конкретное решение, которое поможет перейти на следующий уровень.
Семь ключевых признаков, по которым можно безошибочно определить, кто действительно вырос, а кто лишь притворяется.
Джун в маске сеньора
Этот тип разработчика внешне уже не выглядит новичком. Он легко оперирует модными терминами, посещает метапы и тренинги, но за технической болтовнёй скрывается отсутствие глубинного понимания. Он может эффектно говорить о полиморфизме, асинхронности и инъекциях зависимостей, но сам не до конца понимает, что стоит за этими словами.
ИИ-зависимость
Когда-то это был синдром «копипасты» со Stack Overflow. Сегодня — новое поколение зависимости: от нейросетей. Всё начинается с удобства — автодополнение, готовые сниппеты, помощь в дебаге. Но со временем инструменты становятся костылём, без которого разработчик чувствует себя беспомощным.
Мастер временных решений
Это один из самых распространённых и опасных признаков старого джуна. В условиях дедлайнов, давления, багов на проде и непрерывного потока задач, он начинает использовать «временные решения» — быстрые костыли, которые якобы потом будут переписаны.
Переусложнитель
Переусложнитель — это не обязательно джун. Это скорее переходная форма: разработчик, обладающий уже неплохими знаниями, но не научившийся правильно дозировать их применение. Он знает архитектурные паттерны, умеет строить сложные системы, но не понимает, когда это уместно, а когда — просто избыточно.
Скоростной гонщик
Это разработчик, который поставил скорость выше всего остального. Быстрее закрытые тикеты, больше строк кода, меньше обсуждений. На первый взгляд — мечта менеджера. Но только до тех пор, пока не наступает фаза изменений. Проблема не в скорости как таковой. Проблема в игнорировании качества. Код гонщика часто не покрыт тестами, написан без оглядки на читаемость и сопровождение, перегружен неочевидной логикой.
Архитектор незаменимости
Этот тип разработчика не просто пишет код — он строит лабиринты. Сложные, запутанные, полные нестандартных решений, нестабильных зависимостей и неписаных правил. Не потому что так надо, а потому что это делает его единственным, кто может с этим разобраться.
Мастер пустых ревью
Самый тихий и коварный из всех. Он не пишет плохой код, не строит сложных систем, не тянет на себе костыли. Он просто не мешает плохому коду попадать в прод. Потому что не делает ревью по-настоящему.
👉 @seniorFront
🐙 CSS-Protips – подборка из 29 полезных советов по работе со стилями. В некоторых пунктах есть ссылки на документацию и примеры кода.
Сайтодел | #репозиторий #github
Original post link: t.me/sitodel/2305
Forwarded and filtered by @smartfeed_bot
Сайтодел | #репозиторий #github
Original post link: t.me/sitodel/2305
Forwarded and filtered by @smartfeed_bot
React vs Vue – подробное сравнение и перспективы
В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (например, Next.js и Nuxt, Zustand и Pinia), использование в бэкенде, популярность решений в энтерпрайзе и понимание разработчиками и LLM моделями.
Original post link: t.me/seniorFront/5231
Forwarded and filtered by @smartfeed_bot
В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (например, Next.js и Nuxt, Zustand и Pinia), использование в бэкенде, популярность решений в энтерпрайзе и понимание разработчиками и LLM моделями.
Original post link: t.me/seniorFront/5231
Forwarded and filtered by @smartfeed_bot
Forwarded from Senior Frontend - javascript, html, css
Какие протоколы взаимодействия существуют в WEB?
В сфере веб-разработки и сетевых технологий существует множество протоколов взаимодействия, каждый из которых предназначен для решения определённых задач. Вот некоторые из наиболее распространённых и важных протоколов:
HTTP (HyperText Transfer Protocol)
Это основной протокол для передачи данных в интернете, используемый для загрузки веб-страниц (HTML, CSS, JavaScript и изображений) от сервера к клиенту, обычно веб-браузеру. HTTP определяет методы (например, GET и POST), которые клиенты могут использовать для выполнения запросов к серверам.
HTTPS (HTTP Secure)
Это расширение HTTP, обеспечивающее зашифрованное соединение между клиентом и сервером. Это критически важно для обеспечения безопасности данных пользователя, особенно при передаче конфиденциальной информации, такой как логины и пароли, платёжные данные.
WebSocket
Это протокол, позволяющий устанавливать двусторонние интерактивные соединения между браузером пользователя и сервером. Это особенно полезно для создания веб-приложений, требующих реального времени обмена данными, таких как чаты, игры и торговые платформы.
FTP (File Transfer Protocol)
Это стандартный протокол передачи файлов между компьютерами по сети. Он используется для загрузки и скачивания файлов с сервера, администрирования сайтов и управления содержимым сервера.
SMTP (Simple Mail Transfer Protocol)
Это протокол для отправки электронных писем. Он используется почтовыми серверами для доставки отправленных писем в почтовые ящики получателей.
MAP (Internet Message Access Protocol) и POP3 (Post Office Protocol version 3)
Это протоколы, используемые для извлечения электронной почты из почтового сервера. IMAP предлагает более сложные функции по сравнению с POP3, включая возможность работы с электронной почтой непосредственно на сервере, что позволяет пользователям доступ к почте с разных устройств.
TCP/IP (Transmission Control Protocol/Internet Protocol)
Это основные протоколы, лежащие в основе интернета, обеспечивающие передачу данных между различными устройствами в сети. Он отвечает за установление соединения и гарантию доставки данных, в то время как IP обеспечивает адресацию и маршрутизацию пакетов данных.
DNS (Domain Name System)
Это система, которая переводит доменные имена в IP-адреса, позволяя пользователям легко находить веб-сайты в интернете без необходимости запоминать числовые IP-адреса.
Эти протоколы являются ключевыми для функционирования интернета и веб-технологий, обеспечивая различные аспекты передачи данных, безопасности, обмена сообщениями и доступа к ресурсам.
👉 @seniorFront
В сфере веб-разработки и сетевых технологий существует множество протоколов взаимодействия, каждый из которых предназначен для решения определённых задач. Вот некоторые из наиболее распространённых и важных протоколов:
HTTP (HyperText Transfer Protocol)
Это основной протокол для передачи данных в интернете, используемый для загрузки веб-страниц (HTML, CSS, JavaScript и изображений) от сервера к клиенту, обычно веб-браузеру. HTTP определяет методы (например, GET и POST), которые клиенты могут использовать для выполнения запросов к серверам.
HTTPS (HTTP Secure)
Это расширение HTTP, обеспечивающее зашифрованное соединение между клиентом и сервером. Это критически важно для обеспечения безопасности данных пользователя, особенно при передаче конфиденциальной информации, такой как логины и пароли, платёжные данные.
WebSocket
Это протокол, позволяющий устанавливать двусторонние интерактивные соединения между браузером пользователя и сервером. Это особенно полезно для создания веб-приложений, требующих реального времени обмена данными, таких как чаты, игры и торговые платформы.
FTP (File Transfer Protocol)
Это стандартный протокол передачи файлов между компьютерами по сети. Он используется для загрузки и скачивания файлов с сервера, администрирования сайтов и управления содержимым сервера.
SMTP (Simple Mail Transfer Protocol)
Это протокол для отправки электронных писем. Он используется почтовыми серверами для доставки отправленных писем в почтовые ящики получателей.
MAP (Internet Message Access Protocol) и POP3 (Post Office Protocol version 3)
Это протоколы, используемые для извлечения электронной почты из почтового сервера. IMAP предлагает более сложные функции по сравнению с POP3, включая возможность работы с электронной почтой непосредственно на сервере, что позволяет пользователям доступ к почте с разных устройств.
TCP/IP (Transmission Control Protocol/Internet Protocol)
Это основные протоколы, лежащие в основе интернета, обеспечивающие передачу данных между различными устройствами в сети. Он отвечает за установление соединения и гарантию доставки данных, в то время как IP обеспечивает адресацию и маршрутизацию пакетов данных.
DNS (Domain Name System)
Это система, которая переводит доменные имена в IP-адреса, позволяя пользователям легко находить веб-сайты в интернете без необходимости запоминать числовые IP-адреса.
Эти протоколы являются ключевыми для функционирования интернета и веб-технологий, обеспечивая различные аспекты передачи данных, безопасности, обмена сообщениями и доступа к ресурсам.
👉 @seniorFront
Освойте Promises в JavaScript: пошаговое руководство
Асинхронный код — неотъемлемая часть современного JavaScript. Промисы (Promise) помогают управлять такими операциями, обеспечивая чистый и понятный синтаксис. В этом руководстве вы узнаете, как создавать промисы, обрабатывать их состояния (
#фронтенд #javascript #асинхронность
Original post link: t.me/tproger_web/5473
Forwarded and filtered by @smartfeed_bot
Асинхронный код — неотъемлемая часть современного JavaScript. Промисы (Promise) помогают управлять такими операциями, обеспечивая чистый и понятный синтаксис. В этом руководстве вы узнаете, как создавать промисы, обрабатывать их состояния (
pending, fulfilled, rejected) и использовать методы .then(), .catch() и .finally() для управления результатами асинхронных операций. Примеры кода и наглядные схемы помогут закрепить материал и применять его на практике.#фронтенд #javascript #асинхронность
Original post link: t.me/tproger_web/5473
Forwarded and filtered by @smartfeed_bot
Дока
Promise — JavaScript — Дока
Как уйти за значением выражения и вернуться, когда оно будет доступно.
Forwarded from Frontender's notes [ru]
Проверьте, содержит ли строка одинаковое количество "x" и "o". Метод должен возвращать логическое значение и быть нечувствительным к регистру. Строка может содержать любой символ.
Пример кода:
XO("ooxx") => true
XO("xooxx") => false
XO("ooxXm") => true
XO("zpzpzpp") => true // when no 'x' and 'o' is present should return true
XO("zzoo") => falseРешение задачи
function XO(str) {
// Преобразуем строку в нижний регистр
str = str.toLowerCase();
// Подсчитываем количество 'x' и 'o'
let xCount = 0;
let oCount = 0;
for (let char of str) {
if (char === 'x') xCount++;
if (char === 'o') oCount++;
}
// Сравниваем количество 'x' и 'o'
return xCount === oCount;
}
// Примеры использования
console.log(XO("ooxx")); // true
console.log(XO("xooxx")); // false
console.log(XO("ooxXm")); // true
console.log(XO("zpzpzpp")); // true
console.log(XO("zzoo")); // false
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Senior Frontend - javascript, html, css
Про реальный опыт, и нужен ли он
Мой реальный опыт в Angular — почти 11 месяцев, а в общем во фронтенде около 2.5 лет. До этого я работал на React.
Теперь к сути статьи, недавно я решил пооткликаться на вакансии junior и middle Angular разработчиков, везде в сопроводительных письмах указывая, что у меня опыта 10 месяцев, но зато он настоящий а не накрученный.
Я принципиально против накрутки, с моими знаниями я бы мог без проблем добавить 2 года опыта и пройти собес на мидла, но мне такое не нравится, я за честность.
Угадайте результат. Конечно же одни отказы, даже на позиции джунов, некоторые из них требовали быть в офисах в других городах, но я писал, что готов к релокации.
В целом видна тенденция, где работодатели сами подгоняют накрутку опыта, так как не в состоянии разобраться с горой джунов, хотя в Angular пока их не так много, максимум видал в районе 450 откликов, когда на Реакте и больше 1000 бывает.
Но разве так правильно? Если идти дальше во вранье, то можно и собесы проходить с ИИ, и работать потом с gpt o3 или Claude 3.7 sonnet, самостоятельно мало что умея, разве такой квалификации нужны рабочие компаниям? Так может тогда уже в фильтрах не отсеивать джунов с 6–12 месяцев реального опыта, а концентрироваться на них? Ведь если накручивают опыт, то чаще уже от 2х лет, а вот джуны с полгода‑годом опыта, скорее всего имеют опыт реальный.
Знаю нескольких людей с курса который прошёл, они после него накрутили 2 года опыта, без проблем прошли собес и спокойно работают. Понятно что я бы тоже так мог сделать, для эксперимента даже один раз написал 2 года, и приглашения правда начали появляться, причём в крупные компании. Забавно, согласитесь. В целом такая тенденция в IT меня расстраивает, получается накрутка становится единственным способом попасть на работу. Хочется верить что со временем всё подуспокоится.
В целом я с этим уже смирился, так как делаю это не ради денег, а ради удовольствия. И думаю таких как я тут много.
👉 @seniorFront
Мой реальный опыт в Angular — почти 11 месяцев, а в общем во фронтенде около 2.5 лет. До этого я работал на React.
Теперь к сути статьи, недавно я решил пооткликаться на вакансии junior и middle Angular разработчиков, везде в сопроводительных письмах указывая, что у меня опыта 10 месяцев, но зато он настоящий а не накрученный.
Я принципиально против накрутки, с моими знаниями я бы мог без проблем добавить 2 года опыта и пройти собес на мидла, но мне такое не нравится, я за честность.
Угадайте результат. Конечно же одни отказы, даже на позиции джунов, некоторые из них требовали быть в офисах в других городах, но я писал, что готов к релокации.
В целом видна тенденция, где работодатели сами подгоняют накрутку опыта, так как не в состоянии разобраться с горой джунов, хотя в Angular пока их не так много, максимум видал в районе 450 откликов, когда на Реакте и больше 1000 бывает.
Но разве так правильно? Если идти дальше во вранье, то можно и собесы проходить с ИИ, и работать потом с gpt o3 или Claude 3.7 sonnet, самостоятельно мало что умея, разве такой квалификации нужны рабочие компаниям? Так может тогда уже в фильтрах не отсеивать джунов с 6–12 месяцев реального опыта, а концентрироваться на них? Ведь если накручивают опыт, то чаще уже от 2х лет, а вот джуны с полгода‑годом опыта, скорее всего имеют опыт реальный.
Знаю нескольких людей с курса который прошёл, они после него накрутили 2 года опыта, без проблем прошли собес и спокойно работают. Понятно что я бы тоже так мог сделать, для эксперимента даже один раз написал 2 года, и приглашения правда начали появляться, причём в крупные компании. Забавно, согласитесь. В целом такая тенденция в IT меня расстраивает, получается накрутка становится единственным способом попасть на работу. Хочется верить что со временем всё подуспокоится.
В целом я с этим уже смирился, так как делаю это не ради денег, а ради удовольствия. И думаю таких как я тут много.
👉 @seniorFront
👩💻 В чем разница между
В JavaScript операторы
➡️ Пример:
🗣️ Использование === рекомендуется для избегания ошибок, связанных с преобразованием типов. Это помогает сделать код более предсказуемым и читаемым.
Original post link: t.me/frontendnoteschannel/4777
Forwarded and filtered by @smartfeed_bot
== и === в JavaScript?В JavaScript операторы
== и === используются для сравнения, но ведут себя по-разному. == выполняет нестрогое сравнение, при котором JavaScript может преобразовать типы данных для сопоставления значений. В отличие от него, === выполняет строгое сравнение, проверяя как значение, так и тип данных, без приведения типов.➡️ Пример:
console.log(5 == '5'); // true, так как '5' преобразуется к числу
console.log(5 === '5'); // false, так как разные типы данных
console.log(null == undefined); // true, при нестрогом сравнении они считаются равными
console.log(null === undefined); // false, строгий оператор учитывает типы данных
🗣️ Использование === рекомендуется для избегания ошибок, связанных с преобразованием типов. Это помогает сделать код более предсказуемым и читаемым.
Original post link: t.me/frontendnoteschannel/4777
Forwarded and filtered by @smartfeed_bot
⚡️Руководство по JavaScript для начинающих
Автор образовательного контента по фронтенду Wes Bos представил бесплатный сборник заметок по образцу содержания его курса по JavaScript для начинающих. Над этим ресурсом автор работал больше года.
https://wesbos.com/javascript
Original post link: t.me/senior_front/2553
Forwarded and filtered by @smartfeed_bot
Автор образовательного контента по фронтенду Wes Bos представил бесплатный сборник заметок по образцу содержания его курса по JavaScript для начинающих. Над этим ресурсом автор работал больше года.
https://wesbos.com/javascript
Original post link: t.me/senior_front/2553
Forwarded and filtered by @smartfeed_bot
Wes Bos
Beginner JavaScript Notes & Reference
👩💻 Разница между innerHTML и textContent в JavaScript
• innerHTML позволяет получить или изменить HTML-разметку внутри элемента.
• textContent выводит только текстовое содержимое без HTML-тегов
➡️ Пример:
textContent бы
Original post link: t.me/frontendnoteschannel/4790
Forwarded and filtered by @smartfeed_bot
innerHTML и textContent используются для работы с содержимым HTML-элементов, но они работают по-разному.• innerHTML позволяет получить или изменить HTML-разметку внутри элемента.
• textContent выводит только текстовое содержимое без HTML-тегов
➡️ Пример:
const div = document.createElement("div");
div.innerHTML = "Привет мир!";
console.log(div.innerHTML); // Привет мир!
console.log(div.textContent); // Привет мир!
🗣️ Используйте innerHTML, если нужно работать с тегами и разметкой, а textContent — для безопасного вывода текста без HTML.textContent бы
стрее и безопаснее, так как не интерпретирует HTMLOriginal post link: t.me/frontendnoteschannel/4790
Forwarded and filtered by @smartfeed_bot
Без сборщика: подключаем JS-библиотеку напрямую
Чтобы притянуть стороннюю библиотеку в проект, не обязательно городить Webpack или Vite. Здесь разбираются три вида файлов, которые обычно лежат в npm-дистрибутиве: модули ES, «классические» глобальные переменные и CommonJS, способы находить нужный вариант в dist, писать компактный import map и подключать сложные модули даже без Node.
В довесок — чек-лист инструментов (esm.sh, download-esm, JSPM) и подсказки, как определить тип файла за пару секунд.
#фронтенд #javascript
Original post link: t.me/tproger_web/5495
Forwarded and filtered by @smartfeed_bot
Чтобы притянуть стороннюю библиотеку в проект, не обязательно городить Webpack или Vite. Здесь разбираются три вида файлов, которые обычно лежат в npm-дистрибутиве: модули ES, «классические» глобальные переменные и CommonJS, способы находить нужный вариант в dist, писать компактный import map и подключать сложные модули даже без Node.
В довесок — чек-лист инструментов (esm.sh, download-esm, JSPM) и подсказки, как определить тип файла за пару секунд.
#фронтенд #javascript
Original post link: t.me/tproger_web/5495
Forwarded and filtered by @smartfeed_bot
Forwarded from Веб-страница
Что такое примеси (mixins) в JS
Примесь — это набор методов, который вы «подмешиваете» в несколько разных классов, чтобы не дублировать код. Вместо того чтобы создавать огромный класс-«комбайн» или строить сложную цепочку наследования, вы берёте кусочек функциональности — примесь — и добавляете его туда, где он нужен.
Почему вообще понадобились примеси:
1. В JavaScript только одно наследование «по классам». Класс может расширять ровно один другой класс (extends). Если же необходимо поделиться возможностями между несколькими иерархиями, наследование начинает «скрипеть».
2. Составление (composition) гибче, чем наследование. Примеси позволяют «составлять» объект из маленьких независимых блоков логики, не связывая их жёстко цепочкой «родитель → потомок».
Как это выглядит в коде:
Вы только что сделали любого User умеющим писать лог в консоль, не меняя иерархию классов.
Начиная с ES2015, популярна форма, где примесь — это функция, возвращающая класс:
Так вы оборачиваете любой базовый класс, не трогая оригинальную цепочку extends.
Плюсы примесей:
1. Повторное использование кода. Один раз написали — применили в нескольких местах, избавившись от копипаста.
2. Гибкая композиция. Собираете объект как конструктор LEGO из маленьких блоков логики.
3. Изолированность обязанностей. Каждая примесь решает одну задачу, поэтому код легче читать и тестировать.
#простымисловами #javascript #основы
Примесь — это набор методов, который вы «подмешиваете» в несколько разных классов, чтобы не дублировать код. Вместо того чтобы создавать огромный класс-«комбайн» или строить сложную цепочку наследования, вы берёте кусочек функциональности — примесь — и добавляете его туда, где он нужен.
Почему вообще понадобились примеси:
1. В JavaScript только одно наследование «по классам». Класс может расширять ровно один другой класс (extends). Если же необходимо поделиться возможностями между несколькими иерархиями, наследование начинает «скрипеть».
2. Составление (composition) гибче, чем наследование. Примеси позволяют «составлять» объект из маленьких независимых блоков логики, не связывая их жёстко цепочкой «родитель → потомок».
Как это выглядит в коде:
// 1. Описываем примесь как обычный объект с методами
const canLog = {
log(message) {
console.log(`[${this.name}] ${message}`);
}
};
// 2. Функция-помощник, которая «подмешивает» методы
function applyMixin(targetClass, mixin) {
Object.assign(targetClass.prototype, mixin);
}
// 3. Используем
class User {
constructor(name) { this.name = name; }
}
applyMixin(User, canLog);
const u = new User('Анна');
u.log('Привет!'); // [Анна] Привет!
Вы только что сделали любого User умеющим писать лог в консоль, не меняя иерархию классов.
Начиная с ES2015, популярна форма, где примесь — это функция, возвращающая класс:
const TimestampMixin = (Base) => class extends Base {
get createdAt() {
if (!this._createdAt) this._createdAt = Date.now();
return this._createdAt;
}
};
class Article {}
class Comment {}
class ArticleWithTime extends TimestampMixin(Article) {}
class CommentWithTime extends TimestampMixin(Comment) {}Так вы оборачиваете любой базовый класс, не трогая оригинальную цепочку extends.
Плюсы примесей:
1. Повторное использование кода. Один раз написали — применили в нескольких местах, избавившись от копипаста.
2. Гибкая композиция. Собираете объект как конструктор LEGO из маленьких блоков логики.
3. Изолированность обязанностей. Каждая примесь решает одну задачу, поэтому код легче читать и тестировать.
#простымисловами #javascript #основы