Всем йо, хабражители.
В общем, так вышло, что я пишу на JavaScript уже довольно долго, и одной из самых главных задач всегда была организация состояния приложения.
TL; DR;
Нет ничего привычнее на свете,
Чем писать колесо на велосипеда
Что-то хочется кешировать, что-то обновлять, причем обновлять везде, а не только в локальном компоненте, не хочется перерисовывать весь компонент если поменялся весь Store (shout out to Vuex), а хочется подписываться на то, что используешь (shout out to MobX).
200 байт для управления состоянием React-компонентов
Главный вопрос: чем этот пакет лучше, чем Redux? Ну...
Разработка на javascript иногда становится похожа на работу детектива. Как понять чужой код? Хорошо, если разработчик обладает тонким искусством называть переменные так, чтобы другие поняли суть. А как быть, если члены команды все таки не всегда способны понять замысел своего коллеги? Как понять, что приходит в аргумент какой-либо функции?
Предположим, что аргумент функции называется errors. Вероятно в errors находится массив. Скорее всего строк? Ну то, что массив это понятно. Ведь далее проверяется его длина. Но свойство length есть и у строки. Похоже, чтобы точно разобраться, необходимо поставить breakpoint и запустить скрипт. Затем полностью пройти по сценарию на UI (например нам нужен финальный шаг формы). Теперь в devtools видно, что errors — это объект с набором определенных полей, среди которых и поле length.
Подобная неоднозначность при разборе javascript кода приводит к пустой трате времени разработчика. Неплохим решением в данном случае может стать typescript (далее ts). Можно использовать его в следующем проекте, а еще лучше сделать поддержку ts в существующем. После этого время на понимание чужого кода сократится значительно. Ведь, чтобы понять структуру любых данных достаточно одного клика. Можно сконцентрироваться на логике работы с данными и в любой момент времени знать, что вы однозначно понимаете работу кода.
"Вы поймете, когда вам нужен 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 и попробуем сделать свое.
Благодаря тому, что React предоставляет удивительные возможности по работе с отображением, можно сосредоточиться только на организации логики приложения и семантике кода, описывающего работу с данными. Т.е. выбирая state management библиотеку, происходит выбор стилистики будущей кодовой базы.
В данной статье мы рассмотрим подход, основанный на сервисах-сторах, реализуемый благодаря библиотеке lamp-luwak.
Допустим, перед вами стоит задача написать фронтенд-приложение. Есть ТЗ с описанием функционала, тикеты в баг-трекере. Но выбор конкретной архитектуры лежит на вас.
Порой трудно заранее понять, какая архитектура будет удачной, а какая нет. Особую сложность представляет организация управления состоянием. Как лучше всего хранить и синхронизировать данные, которые нужно отображать? Каждый по-своему подходит к решению этой проблемы и либо пишет весь код сам, либо берет готовую библиотеку. Любой из этих способов — со своими плюсами и минусами.
В статье я расскажу о своем решении проблемы управления состоянием на примере разных стадий развития приложения.
Обзор библиотеки lens-js и эксперименты с котиками.
Данные — это, в действительности, важная часть Вашего будущего приложения или отдельной библиотеки. Важна их структура, целостность, а также и подходы к организации их хранения и обработки. Задача, прямо скажем, не тривиальна, особенно в масштабах корпоративных проектов. Одно из решений — использование менеджера состояния, об одном из которых, тут пойдёт речь.
В предыдущей статье («Angular Components with Extracted Immutable State») я показал, почему изменение полей компонентов без каких-либо ограничений - это не всегда хорошо, а также представил библиотеку, которая позволяет упорядочить изменения состояния компонентов.
С тех пор я немного изменил её концепцию и упростил использование. На этот раз я сосредоточусь на простом (на первый взгляд) примере того, как eё можно использовать в сценариях, где обычно потребовался бы rxJS.
В процессе моей работы в geoalert.io я не раз сталкивался с проблемой управления состоянием приложения на React со встроенной картой mapbox-gl.
Я планирую посвятить теме цикл из трех статей, включая эту:
1. Управление состоянием mapbox-gl в React
2. Встраивание mapbox-gl в React
3. Управление состоянием React приложения сmapbox-gl с использованием XState
Доброго времени суток, друзья!
Предлагаю вашему вниманию результаты небольшого исследования, посвященного сравнению Redux и Vuex.
Redux и Vuex — это библиотеки для управления состоянием React и Vue-приложений, соответственно. Каждая из них по-своему реализует архитектуру для создания пользовательских интерфейсов, известную под названием Flux.
Эта статья — перевод оригинальной статьи Craig Buckler "How to Use IndexDB to Manage State in JavaScript".
В этой статье объясняется, как использовать IndexedDB для хранения состояния в типичном клиентском приложении на JavaScript.
Код доступен на Github. Он представляет собой пример to-do приложения, которое вы можете использовать или адаптировать для своих собственных проектов.
Я хотел бы поговорить о том, что мне редко попадалось на глаза в статьях о MobX, о тех неприятных моментах, что портят впечатление от использования, а так же о способах решения этих моментов. И не обойдусь без описания плюсов, чтобы оправдать собственный выбор. Начнем.
MobX – менеджер состояния, к этому времени 6 версии, которая работает благодаря Proxy. Далее мнение основано на использовании MobX v6 в связке с библиотекой React при разработке мобильных (React Native) и веб-приложений. Стоит уточнить, что я пользовался в прежних проектах MobX v4, react-easy-state, Redux, Zustand, а также ознакомлен с десятком альтернативных менеджеров состояния на уровне чтения их документации. Так же замечу, что все приведенные далее плюсы и минусы не полны и выведены в сравнении с другими менеджерами состояния.
Привет, друзья!
Предлагаю вашему вниманию результаты небольшого исследования, посвященного сравнению Redux и Vuex. Это вторая часть статьи, вот ссылка на первую.
Redux и Vuex — это библиотеки для управления состоянием приложений, написанных на React и Vue, соответственно. Каждая из них по-своему реализует архитектуру для создания пользовательских интерфейсов, известную под названием Flux.
Привет, друзья!
В этом небольшом "туториале" я хочу показать вам, как реализовать простое, но эффективное решение для управления состоянием React-приложений.
Немного забегая вперед, скажу, что решение получилось чуть менее производительным, чем "классическое" сочетание хука useReducer() и инструментов, предоставляемых Context API (которые, собственно, и составляют ядро решения).
Решение представляет собой результат нескольких экспериментов, направленных на максимальное упрощение работы с контекстом React, и во многом вдохновлено Vuex — официальным инструментом для управления состоянием Vue-приложений.
Решение не является законченным и находится в стадии активной разработки, поэтому приветствуются любые замечания и предложения, любая конструктивная критика.
Пока мне не представилось возможности испытать решение в "полевых условиях" (я намерен сделать это при первом удобном случае), но кажется, что оно подойдет для разработки приложений любой сложности при соблюдении двух важных условий:
Здравствуйте, меня зовут Дмитрий Карловский и я… прилетел к вам на турбо-реактивном самолёте. Основная суть реактивного двигателя изображена на картинке.
Тут, казалось бы, хаотичное взаимодействие между молекулами, приводит к тому, что улетающие молекулы опосредованно передают импульс корпусу двигателя. Что ж, давайте подумаем, как реактивные принципы решают или наоборот усугубляют проблемы в программировании. Сравним различные подходы к реактивному программированию. И вытащим на поверхность все их подводные камни.
Это — текстовая расшифровка выступления на SECON.Weekend Frontend'21. Вы можете посмотреть видео запись, прочитать как статью, либо открыть в интерфейсе проведения презентаций.
Обновление данных в интерфейсе всегда задействует немало ресурсов а его реализация может быть выполнена множеством неоптимальных способов. Повышение производительности, не только радует пользователя, но и расширяет круг целевой аудитории с более старыми устройствами. State management Как? Когда? Почему? Каким способом? Лучше всего изменять состояние виджета/древа виджетов? Сейчас можно увидеть большое кол-во различных библиотек и подходов для решения данной задачи. Вопрос обновления данных интерфейса настолько большой, что библиотеки, которые помогают с управлением состояний становятся Архитектурными подходами, паттернами, а статей про то какой подход лучше еще больше. Данное решение подойдет к любому проекту, ему не нужна библиотека и вовсе не обязательно использовать данный виджет.
Привет, друзья!
В этой статье я хочу поговорить с вами об управлении состоянием и повторном рендеринге в React.js.
Что такое состояние и зачем им управлять?
Состояние/state можно определить как любые данные, которые влияют на рендеринг/rendering компонентов. Состояние хранится в реактивных переменных/reactive variables ](в терминологии RxJS).
Управление состоянием/state management — это механизм, позволяющий создавать реактивные переменные, фиксировать изменения их значений и уведомлять об этом "заинтересованные" компоненты. Как правило, такой механизм реализуется с помощью паттерна Издатель-Подписчик/Publisher-Subscriber/Pub-Sub.
Реакция компонентов на изменение состояния часто, но далеко не всегда завершается добавлением/модификацией/удалением HTML-элементов в/из DOM. Как известно, операции, связанные с манипулированием DOM, являются очень медленными. Это обуславливает необходимость грамотного управления состоянием приложений.