Разработчик Эш

В разработке современного приложения нам необходимо пользоваться сторонними сервисами для получения данных, и впоследствии мы сталкиваемся с проблемой CORS. Прокси решает эту проблему: он принимает запрос и перенаправляет его на нужный сервер, позволяя обойти политику безопасности браузера — CORS. Возникает вопрос: почему для обхода CORS нам необходим промежуточный сервер? Дело в том, что CORS — это политика безопасности, реализованная в браузере, а не на сервере. Серверы обычно не блокируют запросы по домену, а браузеры проверяют, разрешено ли вашему сайту читать ответ. Технически это выглядит следующим образом. Когда браузер хочет сделать запрос, он обращается к прокси. Прокси обычно находится на том же адресе, что и сервер разработки (например, localhost:3000). Уже прокси-сервер инициирует запрос к внешнему API и возвращает нам ответ. Таким образом, браузер получает ответ от localhost:3000, а не от конкретного удалённого ресурса. Схема запроса и ответа: Запрос: Клиент → прокси-сервер → целевой сервер. Ответ: Целевой сервер → прокси-сервер → клиент. Настройка прокси в современных frontend-фреймворках несложная, но надо учитывать версию, с которой вы работаете. В новых версиях упростили настройку — реализовать её можно в nuxt.config.ts / next.config.js. Для более сложной логики используйте middleware. Главное — помнить: прокси нужен только на этапе разработки. В продакшене запросы лучше отправлять через свой бэкенд или настраивать CORS по-настоящему. Не усложняйте там, где можно обойтись простыми решениями. Делитесь своим опытом в комментариях или дополните своими мыслями на эту тему.

Хочу затронуть базу. Это очень любопытная тема, в которой путаются даже опытные разработчики. А все почему? Да потому что мы редко сталкиваемся с этим [за исключением блочной, разумеется] в реальной работе, и в конечном итоге это либо забывается, либо мы начинаем путаться в понятиях. Откуда появились функциональная и блочная области видимости? На раннем этапе JS использовали для написания простых скриптов, и не предполагалось создавать большие вложенные структуры кода. Со временем JavaScript эволюционировал, и с появлением стандарта ECMAScript 6 появились let и const. Вероятно, это было сделано для большей предсказуемости и изоляции кода. Да и конкуренцию с другими языками никто не отменял. Принято считать, что у нас есть 3 области видимости. 1. Глобальная область видимости. Переменные, объявленные вне функций и блоков, доступны повсюду в коде. В браузере это объект window, в Node.js — global. Старайтесь избегать подобных объявлений, так как это загрязняет глобальное пространство имен и может привести к конфликтам. 2. Функциональная область видимости. Переменные, объявленные внутри функций, доступны только в ее пределах и в ее вложенностях. Если с let и const тут всё понятно, то у var есть важная особенность: переменная, созданная внутри блока if или цикла for, будет доступна и после этого блока (в пределах всей функции). Это происходит из-за того, что var поднимается в начало своей области видимости (функции) и определяется как undefined до момента инициализации. 3. Блочная область видимости. Переменные, объявленные через let и const, доступны только в границах блока {...}, где они объявлены, и ниже по вложенности. Теперь небольшой, но важный момент про поднятие (hoisting). · let, const, var — все они поднимаются (hoisted) в начало своей области видимости. Однако let и const до момента объявления попадают во временную мертвую зону (Temporal Dead Zone). Попытка обратиться к ним до строки объявления приведет к ошибке ReferenceError. · Function Declaration (объявление функции через function foo() {}) — полностью поднимается в начало своей области видимости. Такую функцию можно вызвать до её объявления в коде. · С Function Expression (присвоение функции переменной) есть нюанс, который необходимо знать: getData() // Ошибка var getData = function() { console.log('получил данные') } Переменная getData (через var) поднимется в начало области видимости. До момента выполнения кода инициализации её значение будет undefined. А попытка вызвать undefined как функцию приведет к ошибке. Для let и const с Function Expression ошибка была бы на этапе обращения (из-за TDZ), а не на попытке вызова. В заключение хотелось бы сказать: навряд ли эта тема коснется кого-то из современных разработчиков в виде внезапных ошибок, но эти знания необходимы для лучшего понимания устройства нашего любимого языка.

В этой статье я попробую поделиться своими мыслями касательно того, какой фреймворк лучше, удобнее для разработки и проще для понимания. Сразу сделаю оговорку: я не буду опираться на внешние факторы, такие как рынок труда или количество вакансий. Я сделаю упор на технической части и самом процессе разработки. Первое, что хотелось бы сказать: новичкам и бизнесу я бы рекомендовал Vue. Многие решения уже заложены «из коробки»: например, маршрутизация и собственный state manager. Тут не буду останавливаться подробно, так как в большей степени это дело вкуса, но стоит учитывать, насколько хорошо эти инструменты интегрированы в экосистему. А теперь перейду к фишкам фреймворков, к тому, что мне нравится. Организация кода. В React мне нравится гибкость в организации компонентов. Я имею в виду возможность создавать в одном файле несколько компонентов и экспортировать их. Vue в этом плане следует строгому принципу SFC (Single File Component): в файле с расширением .vue может лежать только один логический компонент (шаблон + скрипт + стили). Это накладывает дисциплину, но иногда хочется той самой react-свободы. Работа с данными. Что касается создания переменных и работы с ними, я бы отдал предпочтение Vue. Во Vue есть несколько способов создания реактивных данных, одно из самых распространенных — это функция ref(). Если коротко: в отличие от useState в React, если мы хотим изменить значение, мы просто присваиваем новое: const count = ref(0); count.value = 5; // присвоение И нам не надо вызывать функцию setState для обновления состояния, что вызывает лишние рендеры компонента. Кстати, если вы сразу вспомнили про useMemo, то во Vue есть аналог — computed. Это отдельная большая тема про реактивность и вычисляемые значения. Рендеринг и производительность. Плавно подойдя к теме рендеров, тут с практической точки зрения я не вижу явного преимущества одного перед другим в повседневных задачах. Оба работают с Virtual DOM. Однако ключевое отличие в том, что в React при изменении состояния по умолчанию перерендериваются все дочерние компоненты. Vue же благодаря своей системе реактивности отслеживает зависимости точнее и перерендеривает только тот компонент, где произошло изменение, и его непосредственные зависимости. Соответственно, в React разработчик вынужден вручную кэшировать компоненты и значения с помощью React.memo, useMemo, useCallback, чтобы избежать лишней работы. Во Vue ручная мемоизация требуется гораздо реже. Синтаксис и шаблоны. Тут вкусовщина, но добавлю. React использует JSX которая содержит в себе логику и разметку, что для многих плюс. Vue использует HTML-шаблоны и директивы, что позволяет писать условия прямо в тегах. Итог. Если говорить в целом о React и Vue, они во многом схожи: оба приветствуют компонентный подход, принципы и паттерны проектирования у них похожи. React дает свободу выбора инструментов и стиля кодинга, из-за чего сообщество придумало множество архитектурных решений. Vue же более строгий — он предлагает единый стандартный путь решения задач, что упрощает работу в команде.