ReactJS *

В статье речь идет о state colocation, то есть о совместном размещении состояний, этот термин можно было бы еще перевести как стейт колокейшн или стейт колокация.

Одной из основных причин замедления работы React приложения является его глобальное состояние (global state). Я покажу это на примере очень простого приложения, после чего приведу более близкий к реальной жизни пример.

Вот простенькое приложение в котором можно ввести имя для собаки (если окно не работает, вот ссылка):

Если вы поиграете с этим приложением то вскоре обнаружите что оно очень медленно работает. При взаимодействии с любым полем ввода возникают заметные проблемы с производительностью. В такой ситуации можно было бы использовать спасательный круг в виде React.memo и обернуть им все компоненты с медленным рендером. Но давайте попробуем решить эту проблему по другому.

Вот код этого приложения:

Когда я заглядываю в файл {domain}/selectors.js в больших проектах на React/Redux, с которыми работаю, я часто встречаю огромный список redux-селекторов подобного вида:

getUsers(state)
getUser(id)(state)
getUserId(id)(state)
getUserFirstName(id)(state)
getUserLastName(id)(state)
getUserEmailSelector(id)(state)
getUserFullName(id)(state)
…

На первый взгляд использование селекторов не выглядит чем-то необычным, но с опытом мы начинаем понимать — селекторов может накопиться слишком много. И кажется, мы дожили до этого момента.

Что я делаю сейчас

В настоящее время я тестирую реализацию кода. Такие тесты ломаются каждый раз после рефакторинга, особенно в компонентах пользовательского интерфейса. В итоге я провожу кучу времени, копаясь в файлах .test.js, паралельно приследуюя магическую цифру в 80% для Test Coverage.

Что я должен делать

При написании любого типа тестов, включая модульное тестирование, я должен меньше думать о коде который я тестирую, а больше о том, что делает данный код. Это означает писать тесты, имитирующие поведение пользователя. Даже на самом низком уровне.

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

Если вы уже писали код который используется больше чем в одном месте, то вам знакома такая ситуация:

1. Вы создаете многократно используемый фрагмент кода (это может быть функция, React компонент, React хук и тд) и делитесь им (для совместной работы или публикуя в опенсорс).
2. Кто-то обращается к вам с просьбой добавить новый функционал. Ваш код не поддерживает предложенный функционал, но мог бы, если бы вы сделали небольшое изменение.
3. Вы добавляете новый аргумент/проп/опцию в свой код и в связанную с ним логику для поддержания работы этого нового функционала.
4. Повторите стадии 2 и 3 несколько раз (или много-много раз).
5. Теперь ваш повторно используемый код тяжело использовать и поддерживать.

Что именно делает код кошмаром для использования и поддержки? Есть несколько аспектов, которые могут сделать ваш код проблемным:

Управление состоянием — одна из важнейших задач, решаемых в разработке на React. Было создано множество инструментов в помощь разработчикам для решения этой задачи. Наиболее популярным инструментом является Redux — небольшая библиотека, созданная Дэном Абрамовым, и предназначенная помочь разработчикам использовать паттерн проектирования Flux в их приложениях. В этой статье мы разберем, действительно ли нам нужен Redux, и посмотрим, как мы можем заменить его более простым подходом, в основе которого лежат Observable и React Hooks.

"Вы поймете, когда вам нужен Flux. Если вы не уверены, что вам это нужно, вам это не нужно." Пит Хант

Для управления состоянием приложения я как правило применяю Redux. Но не всегда есть необходимость в использовании модели Action\Reducer, хотя бы из-за трудозатратности ее применения для написания простейшего функционала. Возьмем в качестве примера обычный счетчик. На выходе хотелось получить простое и практичное решение, которое позволит описать модель состояния и пару методов его меняющие, наподобие такого:

state = {value: 0} 
increase() { 
  state.value += 1 
} 
decrease() {
  state.value -= 1
}

Сходу кажется, что такое решение может обеспечить MobX, так почему бы им и не воспользоваться? Поработав с MobX некоторое время, для себя пришел к выводу, что лично мне проще оперировать последовательностью иммутабельных состояний (наподобие Redux), чем логикой мутабельного состояния (наподобие MobX), да и его внутреннюю кухню я бы не назвал простой.

В общем, захотелось найти простое решение для управления состоянием, в основе которого лежала бы иммутабельность, с возможностью применять его в Angular\React и реализованное на TypeScript. Беглый обзор на просторах github подходящего решения не выдал, поэтому возьмем RxJS/Immer и попробуем сделать свое.

Приветствую Хабр! Представляю вашему вниманию перевод статьи — Asynchronous Redux Actions Using Redux Thunk, автора — Alligator.io

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

Меня зовут Иван, я frontend-разработчик. В этой статье вместе с коллегой и DIY-энтузиастом lilek Юрой Лилековым мы расскажем, как при помощи двух красных кнопок, одного микроконтроллера, кода на React и 250 слов на айти-тематику мы сделали игру «IT-угадайка» и собрали уютную тусовочку на Highload++ и Heisenbug.

Всем привет!

До нового года остаются считанные дни. Наткнулся на свой список дел, которые собирался сделать в 2019-м, среди них оказалось и написать статью на Хабр. Самое время заскочить в уходящий вагон).

Сразу оговорюсь, пиарю свой велосипед, если такое Вам не по душе, то можете смело пропускать статью.

Что такое локализация?

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

В настоящее время разработка львиной доли веб-приложений, основанных на фреймворке React, ведется с использованием библиотеки Redux. Данная библиотека является самой популярной реализацией FLUX-архитектуры и, несмотря на ряд очевидных преимуществ, имеет весьма существенные недостатки, такие как:

• сложность и “многословность” рекомендованных паттернов для написания и организации кода, что влечет за собой большое количество бойлерплейта;
• отсутствие встроенных средств управления асинхронным поведением и побочными эффектами, что приводит к необходимости выбора подходящего инструмента из множества аддонов, написанных сторонними разработчиками.

Для устранения этих недостатков разработчики Redux представили библиотеку Redux Toolkit. Этот инструмент представляет собой набор практических решений и методов, предназначенных для упрощения разработки приложений с использованием Redux. Разработчики данной библиотеки преследовали цель упростить типичные случаи использования Redux. Данный инструмент не является универсальным решением в каждом из возможных случаев использования Redux, но позволяет упростить тот код, который требуется написать разработчику.

В данной статье мы расскажем об основных инструментах, входящих в Redux Toolkit, а также, на примере фрагмента нашего внутреннего приложения, покажем, как их использовать в уже имеющемся коде.

В официальной документации React Native, из раздела Getting Started, мы узнаем о том, что у нас есть два пути запуска мобильного приложения: expo и react-native cli. Пользователи Windows и Linux, а таких большинство, зайдя во вкладку Building Projects with Native Code и выбирая Target OS: iOS, встречают надпись, которая отправляет их на стартер Expo, но перед тем как ставить Expo, предлагаю ознакомиться с информацией в следующей таблице и поберечь свою голову не только от тех тумаков, что получил я: