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

Библиотека, которая использует концепцию неконтролируемых компонентов, чтобы минимизировать количество повторных рендеров и повысить производительность приложения. Данная статья полезна для новичков, которые только начинают работать со сложными формами в React.

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

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

Синдром IE6. Adobe купила вполне годный продукт, и полностью на него забила. Прошли десятилетия прежде чем unity занял ту же нишу в разработке игр, а веб-игры закончились уже навсегда. Flash анимация тоже к сожалению умерла.
Нужно было открыть технологию, разрешить использовать компоненты по отдельности (графический движок, action script), и сосредоточиться на продаже инструментов разработки.
Этот же подход стремительно убивает java как платформу.

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

Все фронтендеры любят localStorage — ведь в него можно прикопать данные без всяких баз и серверов. Но из localStorage можно отлично обстрелять себе ногу — сегодня расскажу про 6 встроенных пулеметов:

Коллизии ключей
Изменение схемы данных
Рассинхрон схемы на чтение и на запись
Ошибки setItem
Чтение localStorage в SSR
Отсутствие изоляции между пользователями

Сейчас любой сайт имеет адаптивную верстку, и CMS не исключение. Но если мы встраиваем приложение через iframe, то компонент должен реагировать на изменение ширины страницы. Если iframe занимает 100% ширины страницы, то можно просто подписаться на событие resize в нашем Angular-компоненте или написать media query в стилях. Таким образом, мы сможем работать с адаптивностью контента внутри iframe.

Но если компонент не может занимать всю ширину, а, допустим, есть колонка в 500—600 пикселей, то придется придумывать различные ухищрения. Особенно если потребуется кастомизация адаптивности для разных страниц, например разный размер ширины колонки и разные breakpoint-ы. Внутри приложения придется вместо css-breakpoint использовать свои размеры и уметь с ними работать. Такое поведение может свести с ума, особенно при переходе от десктопной версии к мобильной и обратно.

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

На короткой дистанции выигрывают те, кто игнорирует «как и почему» в пользу «здесь и сейчас».

В долгой гонке выигрывают те, кто зачем-то, из непонятного интереса, отстают, отходят от бегущих, начинают «копать к первоисточнику» и в какой-то момент понимают, как и почему всё устроено. И зачем. Вот им открываются чит-коды, обходные пути и возможность предсказывать перспективные направления. Остальные продолжают бежать.