Привет! Это моя первая статья на Хабре и в ней я хочу рассказать о, первой мной написанной, библиотеке для работы с формами. Но сперва, давайте поговорим о том, как должна выглядеть идеальная библиотека для работы с формами.
В этой статье разберем как с помощью useEffect воспроизвести методы жизненного цикла в функциональных компонентах. Поговорим как и когда использовать useEffect и useLayoutEffect. Обсудим особенности отправки запросов из useEffect. Также узнаем почему массив зависимостей необязателен и когда это может пригодиться.
В прошлой статье про работу с состоянием пользователь нажимал кнопки и запускалось изменением состояние. Но представьте ситуацию, когда мы хотим, чтобы состояние изменялось не напрямую от действий пользователя, а в следствии внутренней логики программы. В этом помогут хуки useEffect и useLayoutEffect.
Когда мы имеем дело с большим проектом, в репозитории которого накопились десятки тысяч строк кода, иногда единственным здравым решением кажется все переписать с нуля, а не оптимизировать. С точки зрения бизнеса может возникнуть вопрос: а почему вообще нужно оптимизировать или даже переписывать приложение, если оно работает? Дело в том, что по мере роста кодовой базы есть вероятность увеличения дублирующихся компонентов/фрагментов кода, появления устаревших участков, которые тормозят сборку, но полезной нагрузки уже не несут. Это негативно влияет на скорость работы приложения и увеличивает срок разработки.
В этом кейсе мы покажем, как улучшить имеющееся решение с точки зрения архитектуры, а также рассмотрим библиотеки и их особенности, которые помогут сделать приложение быстрее.
В данном примере мы имеем дело с довольно объемной кодовой базой, UI которой обрабатывает большие массивы данных и выводит их на экран в виде списков, таблиц, графиков. Поэтому нам важно обеспечить гибкость нашего приложения как в плане сборки бандла, так и для развертывания в разных средах. И, конечно, иметь в рукаве самые последние фичи, позволяющие делать наш код красивым, понятным и читаемым.
Статья будет полезна тимлидам и техлидам проектов, а также разработчикам, которые столкнулись с развертыванием крупных неоптимизированных React-приложений.
Дайджест новостей и полезных статей о фронтенд-разработке за последнюю неделю 23–29 мая.
Module Federation — это подход, при котором можно разделить приложение на небольшие отдельные модули и в рантайме объединять в единое приложение. Это одно из немногих рабочих решений для разработки микрофронтендов. Почему оно лучше, чем остальные, какие еще решения для микрофронтендов существуют, что вообще такое микрофронтенды и зачем они нам нужны, расскажу в статье. В конце поделюсь полезными ссылками на статьи, видео и документацию, которые помогут углубиться в тематику Module Federation.
Так же будет немного практики. Настоятельно рекомендую самостоятельно опробовать технологию чтобы материал хорошо закрепился в памяти. Практика наше все!
Статья поможет новичкам понять как работать с хуками, а также будет полезна и опытным разработчикам. Этой статьей открываю серию статей про хуки.
Использование хуков с одной стороны позволяет использовать методы жизненного цикла в функциональных компонентах и призваны улучшать производительность, что делает функциональные компоненты полноценным конкурентом классовых компонентов. С другой стороны, неправильное использование хуков приводит к лишним операциям и может свести на нет все преимущества функциональных компонентов.
В этой серии статей разберем основные хуки реакта и как их правильно использовать.
В данном переводе рассказывается о том, что такое мемоизация, зачем её использовать. Также представлены основные примеры на JavaScript и React, демонстрирующие работу мемоизации.
Vitest — это новая среда тестирования на базе Vite. Он все еще находится в разработке, и некоторые функции могут быть еще не готовы, но это хорошая альтернатива, которую можно попробовать и изучить.
30 марта 2022 года команда инженеров Meta анонсировали новую версию React Native 0.68. Помимо различных минорных улучшений и фиксов эта версия содержит историческое для платформы изменение, впервые мы можем попробовать в своих приложениях так называемую новую архитектуру. Давайте вместе разберемся что это за новая архитектура и почему к ней шли без малого 4 года.
В этой статье используется базовая компоновка с родительским и дочерними компонентами для демонстрации внутренних процессов архитектуры Fiber, на которую опирается React для передачи пропсов в дочерние компоненты.
Случалось ли вам, выполняя какую-то задачу, понять, что самый простой путь — нажать Сtrl+C, Сtrl+V: перетащить из соседней папочки пару файлов, поменять пару строчек, и будет ок? Повторялось ли это ощущение? Я хочу рассказать о том, как боролся с этой проблемой и к чему пришёл вместе с командой. Назовём это решение «универсальные компоненты» (если у кого-то будет более удачное название для концепции, жду в коментариях). Примеры буду приводить в основном на React, но концепции будут общие. 
Погрузитесь глубоко в новую архитектуру React под названием Fiber и узнайте о двух основных фазах нового алгоритма согласования (reconciliation). Мы подробно рассмотрим, как React обновляет состояние и пропсы и обрабатывает дочерние элементы.
Вы когда-нибудь задумывались о селекторе CSS, где вы проверяете, существует ли конкретный элемент внутри родителя? Например, если у компонента карты есть миниатюра, нам нужно добавить к нему display: flex. Это было невозможно в CSS, но теперь у нас будет новый селектор CSS :has, который поможет нам выбрать родителя определенного элемента и многое другое.
В этой статье я объясню проблему, которую решает :has, как он работает, где и как мы можем его использовать с некоторыми вариантами использования и примерами, и, самое главное, как мы можем использовать его уже сегодня.
Кто бы что не говорил о метриках производительности, мол это все ерунда и никому кроме гугла не нужно. Но, во-первых, я так не считаю, а во вторых у нас есть заказчики, которым это важно
и они задачи по оптимизации производительности нам ставят, и, даже если по Вашему высокопрофессиональному мнению они заблуждаются, то делать их надо.
Не буду пересказывать рекламные лозунги про 500% пользователей покидают страницу после 100мс ожидания, увелечения конверсии на 20% при снижении LCP на 2мс… читайте сами. Скажу коротко: метрики производительности важны.
Казанская IT-компания объявила набор стажёров, которым предстоит заниматься сборкой интерактивных фильмов. Работать нужно будет удалённо, так что рассматриваются кандидаты со всей России и других стран. Основное требование - знание одного из языков: Kotlin, Android SDK / Swift, iOS SDK, UIKit / JavaScript, React. Рассматривают студентов и выпускников IT-направлений, которые находятся в поисках интересного опыта.
Почитать подробности и подать заявку до 21 апреля можно здесь: hr.movika.com
Movika разрабатывает IT-решения для интерактивного видео: инструменты для его создания, просмотра, монетизации и экспорта. Цель компании - сделать так, чтобы формат интерактивного контента становился повсеместным и популярным.
За последние несколько лет управление состоянием в React претерпело значительные изменения. Многие перешли с Flux на Redux и ищут еще более простые решения. Кроме того, появление React Hooks открыло новые возможности для управления состоянием.
Некоторые из новых библиотек управления состоянием, которые появились на горизонте, — это Recoil, Jotai, Radio Active state и Zustand.
В этой статье я расскажу о Zustand, который предоставляет легкий и простой способ управления состоянием в React.
Привет, когда разрабатываем любой проект на React, мы, при выборе что рендерить, больше всего имеем дело с условными операторами или просто с передачей компонентов в определенный компонент, функцию или тому подобное. Но если происходит неожиданная ситуация и в React компоненте или функции случается ошибка, то, зачастую мы видим белый экран смерти. И после этого нам надо открыть инструменты разработчика, чтобы увидеть в консоли ошибку. А это точно не лучший способ обработки ошибок. Решением данной проблемы является Error Boundary.
Привет, в данном посте вы найдете перевод статьи Mangabo Kolawole, в которой пойдет речь о Test-Driven Development. Мы создадим крайне простое приложение на React по всем правилам TDD.
Первое правило Test-Driven Development (TDD) – это написание тестов перед написанием кода. Это звучит более интуитивно, когда мы говорим о разработке для бэкенда, если честно, но работает ли данная схема для фронтенда, в частности для React, что же, посмотрим.
Представляю несколько проектов с исходным кодом начиная от инструментов для повышения производительности до B2B приложений. Решения можно использовать как замену платным.
В статье ставится проблема избыточной сложности использования фреймворка React.js при богатстве его функций, описана возможная тенденция роста технического долга и зависимость между предоставляемыми средствами и величиной технического долга.
Что подразумевается под необоснованной сложностью проектов?
Для начала необходимо отметить, что «React» в отличии от «Vue» предоставляет огромную свободу разработчику. Благодаря этому разработчики любят данный фреймворк и всячески указывают, что приложения на «React» будут быстрее и производительнее чем на «Vue». Это несомненно так, «React» приложения можно сделать быстрым, производительным и легко тестируемым. К сожалению, достичь этого крайне тяжело и из-за этого многие компании могут иметь не высокопроизводительные приложения, а наоборот перегруженные излишним кодом и трудно тестируемые приложения. Это связанно с тем, что начинающим разработчикам сложно понять, как правильно писать приложения на «React».
«React» словно тренер по плаванию, бросает вас в воду и говорит плыви, ему не важно будете вы правильно дышать или махать руками, ему важно чтобы вы плыли. Проецируя данный пример на «React», мы получаем возможность писать очень плохой рабочий код. Особенно это распространено в командах, где нет специалиста по «React». Люди меняются и каждый раз поддерживать приложение все труднее и труднее, кто-то увидел пример в функциональном стиле:
