Современный React все больше соответствует идеалам функционального программирования.
Ежедневно мы пользуемся подходами из мира ФП, зачастую даже не подозревая об этом.
Эти паттерны плотно укоренились в сознании фронтенд-разработчиков, делая наш код значительно чище, читаемее и предсказуемее.
В этой статье мы применим один из функциональных паттернов в React приложении и посмотрим что из этого выйдет.
Привет, меня зовут Дмитрий, я React-разработчик, и сегодня хочу рассказать о методе localeCompare в JavaScript. Мне кажется, что этот метод не так часто используется при сортировке строк, хотя он действительно заслуживает внимания. Многие привыкли к стандартным методам сравнения, но localeCompare позволяет учесть важные нюансы, такие как языковые особенности, регистр символов и числовую сортировку. Я постараюсь раскрыть все его возможности и показать, как можно использовать его для улучшения сортировки данных в проектах.
С ростом приложения и увеличением количества зависимостей, мы осознали необходимость в централизованном управлении зависимостями, выходящем за рамки React и MobX. Существующие IoC-контейнеры показались избыточными и тяжеловесными. Поэтому было создано собственное решение. В статье вы узнаете, как мы решили уравнение :-)
Привет, друзья!
В этой серии статей мы разбираем структуры данных и алгоритмы, представленные в этом замечательном репозитории. Это восьмая часть серии.
Сегодня мы поговорим об алгоритмах сортировки.
Код, представленный в этой и других статьях серии, можно найти в этом репозитории.
Интересно? Тогда прошу под кат.
Удивился, что про столь популярный продукт не было статьи на Хабре, срочно это исправляю. Drizzle ORM — это #2 самая желаемая ORM по опросам, и она даже вошла в top 50 JavaScript Rising Stars 2024, заняв 27 место.
Оптимизация производительности в react - очень тонкая работа, требующая хорошего понимания внутреннего устройства работы библиотеки. Но порой, уже хорошо известные понятия такие как контекст и композиция позволяют неплохо повысить отзывчивость вашего приложения.
Представьте, что к вам приходит владелец с видео-концептом новой фичи для клиента, функционал которой отдаленно напоминает космический корабль, а у вас всего два месяца на разработку, и один — на тестирование. Если смогли представить, значит эта статья для вас, а если нет — то и для вас тоже, чтобы заранее знать, как выходить из таких ситуаций.
В современной разработке веб-приложений одной из ключевых проблем является несовместимость между фронтендом и бэкендом. Фронтенд-команды часто вынуждены ждать, пока бэкенд предоставит необходимые API, а бэкенд-разработчики тратят время на адаптацию логики под изменения в интерфейсе. Это приводит к задержкам в разработке, сложностям в тестировании и постоянным несоответствиям в данных.
Что такое Backend-for-Frontend (BFF)?
Backend-for-Frontend (BFF) — это архитектурный паттерн, который помогает устранить разрыв между фронтендом и бэкендом. BFF выступает промежуточным слоем, который адаптирует данные и логику бэкенда под нужды конкретного фронтенда. Это позволяет фронтенд-командам работать с API сразу, а бэкенд-разработчикам подключать логику по мере готовности, что значительно ускоряет процесс разработки и снижает количество доработок.
Подробная инструкция по разработке трёхфазного энергомонитора на базе ESP8266 с функцией автоматической проверки прибора учёта электроэнергии.
React предоставляет программисту прекрасный базовый набор хуков и с каждой версией их количество и функционал увеличивается.
Трудно представить код современного React-приложения без таких функций как useState, useEffect, useRef и так далее.
Однако, в повседневной жизни мы часто решаем рутинные задачи, многие из которых могут быть автоматизированы.
Создание кастом-хуков это прекрасная возможность выделить часто переиспользуемый код в отдельные сущности.
Это помогает содержать основной код компонента в чистоте и избавляет нас от мелких ошибок, которые могут остаться незамеченными, когда вы пишете один и тот же код заново.
Ниже мы рассмотрим примеры некоторых из них.
Хабр не раз выручал нашу команду, когда заказчик ставил задачу, которую мы никогда не делали. В недавнем кейсе по разработке демо-приложения PWA мы подсмотрели в статьях несколько полезных советов и тоже решили написать о своем опыте. Поговорим о PWA, развитие технологии и про то, кому это выгодно и не очень. Кстати, меня зовут Сергей Филатов и я веб-разработчик в R-Style Softlab.
Исправить опечатку в документации занимало 5 минут компиляции. Страницы с картинками загружались медленно.
Я считаю, чтобы посмотреть документацию не нужен JavaScript. Расскажу как переехал с docusaurus + react на starlight + astro и оптимизировал сайт под экологию.
В данной статье я хочу затронуть такую интересную тему, как обновление бандла Capacitor-приложений (CodePush, live update и т.д).
Сталкивались ли Вы когда-нибудь с ситуацией, когда необходимо незначительно обновить мобильное приложение, написанное на Capacitor?
Предположим такую ситуацию: Вы выпустили релиз приложения, где все изменения не связаны с обновлением нативного кода, то есть Вы не добавляли новых библиотек в приложение, которые содержат нативный код (доступ к камере, NFC и т. д.). Или, допустим, Вы обновили пару строчек в спецификации. Даже ради таких, казалось бы, небольших изменений вам придется делать как минимум один релиз в магазин приложений (а их бывает много).
А если нужно сделать релизы во всех популярных магазинах? Google Play, RuStore, AppGallery и, конечно же, самые нерасторопные из существующих — App Store. Выпуск во всех интересующих магазинах может занять значительное время. Вы, конечно, можете автоматизировать этот процесс при помощи различных инструментов, но, так или иначе, это занимает время на одобрение модераторами.
Привет, Хабр. Я Сергей, фронтенд-разработчик в Clevertec. И сегодня поделюсь опытом использования обновленной 7-й версии React Router. Расскажу, как мы реорганизовали структуру роутинга. Покажу, как избавились от лишних «букав кода», улучшили производительность приложения, создали навигацию по страницам и еще много полезного.
Многие, конечно, знают, что в Angular-сообществе принято трепетно следить за подписками на Observable, потому что это чревато утечками памяти. Но не все видели эти утечки в глаза и не встречались с их последствиями. Давайте смоделируем простую ситуацию по следам утечки, с которой недавно столкнулся я (первый раз).
IDE упрощают рефакторинг, но при работе с большими или распределёнными кодовыми базами, особенно без полного контроля над ними, часто требуется помощь codemods. Используя абстрактные синтаксические деревья (AST), codemods автоматизируют изменения кода с высокой точностью и минимальными усилиями, что особенно полезно при критических изменениях в API.
В статье мы рассмотрим, как codemods решают задачи удаления feature toggles и рефакторинга сложных компонентов React, а также узнаем про типичные подводные камни и как их избежать в крупных проектах.
В предыдущей статье об основах JS мы рассмотрели селекторы HTML элементов, теперь нужно разобраться как манипулировать элементами, после того как они будут найдены. Важной частью этой работы, является взаимодействие с атрибутами HTML элементов.
Как всего одна небольшая React-задача помогает глубже понять уровень кандидата на собеседовании? Разбираем нюансы работы с хуками, асинхронностью, состоянием гонки и сайд-эффектами. На первый взгляд задача кажется простой - всего лишь компонент, загружающий данные по username. Но в процессе решения выявляются ключевые моменты: правильно ли кандидат управляет состоянием, учитывает ли смену пропсов, обрабатывает ошибки и предотвращает race conditions. Этот вопрос помогает не просто проверить знания, а увидеть, как кандидат рассуждает и принимает технические решения.
