У нас много библиотек: с общими утилитами и хуками, стилями, классами базовых сторов, с утилитами для ВК- и ОК-приложений. Во всех этих библиотеках нужно постоянно дополнять и заменять какие-то элементы, а после этого тестировать библиотеки на работоспособность.

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

Рассмотрим несколько основных методов кеширования, таких как использование HTTP заголовков Cache-Control, ETag, и If-Modified-Since, а такжеLocalStorage.

Попробую заглянуть за пределы возможностей языка JavaScript и оценить, как производительность может существенно различаться при написании выразительного, декларативного и лаконичного кода по сравнению с оптимизированным. На примере функции, определяющей, является ли строка палиндромом, я покажу несколько вариантов решения задачи с замерами времени на исполнение. Затем напишу модуль на C, который буду вызывать наряду с методами на JavaScript для замера скорости. Проведу низкоуровневые оптимизации. Все это стало возможно благодаря развитию ИИ.

Случайность, с точки зрения безопасности, имеет значение. Я не специалист по безопасности, но, насколько я понимаю, генератор псевдослучайных чисел (ГПСЧ) считается "безопасным" в том случае, когда последовательность чисел, которую он произведет или уже произвел, не может быть вычислена злоумышленником.

Когда речь идет о "генераторах случайных цветов", таких, как моя утилита для создания цветовой палитры, понятие "случайности" гораздо более расплывчато. В моем случае генерация цвета настолько случайна, насколько это «ощущается» пользователем. Другими словами, эффективность случайности является частью пользовательского опыта (UX).

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 рекомендуется использовать пользовательские хуки, поскольку вспомогательные функции лучше всего подходят для работы без состояния, общего назначения.