Mrr — функционально-реактивная библиотека для React'а (извиняюсь за мнимую тавтологию).
При слове «реактивность» обычно вспоминают Rx.js, как эталонный образец FRP. Однако серия последних статей на эту тему на Хабре([1], [2], [3]) показала громоздкость решений на Rx, которые на несложных примерах проигрывали в ясности и простоте почти любому другому подходу. Rx велик и могуч, и прекрасно подходит для решения проблем, в которых абстракция потока напрашивается сама собой (на практике это преимущественно координация асинхронных задач). Но стали бы вы писать, к примеру, простую синхронную валидацию формы на Rx? Сэкономил бы он ваше время, по сравнению с обычными императивными подходами?
mrr — это попытка доказать, что ФРП может быть удобным и эффективным решением не только в специфических «потоковых» проблемах, но и в самых обычных рутинных задачах фронтенда.
Реактивное программирование — очень мощная абстракция, на данный момент на фронтенде она присутствует в двух ипостасях:
- реактивные переменные (computed variables): просто, надежно, интуитивно понятно, но потенциал РП раскрыт далеко не полностью
- библиотеки для работы с потоками, такие как Rx, Bacon и т.д.: мощно, но достаточно сложно, сфера практического использования ограничена специфическими задачами.
Mrr совмещает плюсы этих подходов. В отличии от Rх.js, mrr имеет краткий API, который пользователь может расширять своими дополнениями. Вместо десятков методов и операторов — четыре базовых оператора, вместо Observable (горячих и холодных), Subject и т.д. — одна абстракция: поток. Также в mrr отсутствуют некоторые сложные концепции, которые могут существенно усложнить читабельность кода, например, метапотоки.
Однако mrr — это не «упрощенный Rx на новый лад». Отталкиваясь от тех же базовых принципов, что и Rx, mrr претендует на бóльшую нишу: управление глобальным и локальным (на уровне компонента) состоянием приложения. Хотя изначально концепция реактивного программирования предназначалась для работы с асинхронными задачами, mrr с успехом использует подходы реактивности и для обычных, синхронных задач. Это и есть принцип «тотального ФРП».
Часто при создании приложения на Реакте используется несколько разнородных технологий: recompose (или в скором времени — хуки) для состояния компонента, Redux/mobx для глобального состояния, Rx посредством redux-observable (или thunk/saga) для управления сайд-эффектами и координации асинхронных задач в Редаксе. Вместо такого «салата» из разных подходов и технологий внутри одного приложения, с mrr вы можете использовать единую технологию и парадигму.
Интерфейс mrr также существенно отличается от Rx и подобных библиотек — он более декларативен. Благодаря абстракции реактивности и декларативному подходу, mrr позволяет писать выразительный и краткий код. К примеру, стандартное TodoMVC на mrr занимает менее 50 строк кода(не считая JSX шаблона).
Но довольно рекламы. Получилось ли совместить преимущества «легкого» и «тяжелого» RP в одном флаконе — судить вам, но сначала прошу ознакомиться с примерами кода.
TodoMVC уже изрядно набил оскомину, а пример с загрузкой данных о пользователях Github слишком примитивен, чтобы на нем можно было прочувствовать особенности библиотеки. Мы будем рассматривать mrr на примере условного приложения для покупки ж/д билетов. В нашем UI будут поля для выбора начальной и конечной станций, даты. Затем, после отправки данных, будет возвращен список доступных поездов и мест в них. Выбрав конкретный поезд и тип вагона, пользователь введет данные пассажиров, и затем добавит билеты в корзину. Поехали.
Нам нужна форма с выбором станций и даты:
Создадим поля с автодополнением для ввода станций.
import { withMrr } from 'mrr';
const stations = [
'Абакан',
'Алматы',
'Альметьевск',
'Белая Церковь',
...
]
const Tickets = withMrr({
// начальные значения потоков
$init: {
stationFromOptions: [],
stationFromInput: '',
},
// вычисляемый поток - "ячейка"
stationFromOptions: [str => stations.filter(s => s.indexOf(str)===0), 'stationFromInput'],
}, (state, props, $) => {
return (<div>
<h3>
Поиск жд билетов
</h3>
<div>
Станция отправления:
<input onChange={ $('stationFromInput') } />
</div>
<ul className="stationFromOptions">
{ state.stationFromOptions.map(s => <li>{ s }</li>) }
</ul>
</div>);
});
export default Tickets;
mrr-компоненты создаются с помощью функции withMrr, которая принимает схему реактивных связей (описание потоков) и render-функцию. Render-функции передаются props компонента, а также state, которым теперь полностью управляет mrr. В нем и будут находится начальные(блок $init) и вычисляемые по формулам значения реактивных ячеек.
Сейчас у нас есть две ячейки (либо два потока, что то же самое): stationFromInput, значения в которую попадают из пользовательского ввода с помощью хелпера $ (передающего по умолчанию event.target.value для элементов ввода данных), и производная от нее ячейка stationFromOptions, содержащая массив подходящих по названию станций.
Значение stationFromOptions автоматически вычисляется каждый раз при изменении родительской ячейки с помощью функции (в терминологии mrr называемой "формула" — по аналогии с формулами Экселя). Синтаксис выражений mrr прост: на первом месте идет функция (либо оператор), по которой высчитывается значение ячейки, затем идет список ячеек, от которых данная ячейка зависит: их значения передаются в функцию. Такой странноватый, на первый взгляд, синтаксис имеет много преимуществ, которые мы позже рассмотрим. Пока что логика mrr тут напоминает обычный подход с computable variables, используемый в Vue, Svelte и других библиотеках, с той лишь разницей, что вы можете использовать чистые функции.
Реализуем подстановку выбранной из списка станции в поле ввода. Также необходимо скрывать список станций после того как юзер кликнет по одной из них.
const Tickets = withMrr({
$init: {
stationFromOptions: [],
stationFromInput: '',
},
stationFromOptions: [str => stations.filter(s => str.indexOf(a) === 0), 'stationFromInput'],
stationFrom: ['merge', 'stationFromInput', 'selectStationFrom'],
optionsShown: ['toggle', 'stationFromInput', 'selectStationFrom'],
}, (state, props, $) => {
return (<div>
<div>
Станция отправления:
<input onChange={ $('stationFromInput') } value={ state.stationFrom }/>
</div>
{ state.optionsShown && <ul className="stationFromOptions">
{ state.stationFromOptions.map(s => <li onClick={ $('selectStationFrom', s) }>{ s }</li>) }
</ul> }
</div>);
});
Обработчик событий, созданный с помощью хелпера $, в списке станций будет эмитировать фиксированные для кажной опции значения.
mrr последователен в своем декларативном подходе, чуждом любым мутациям. Мы не можем после выбора станции «принудительно» изменить значение ячейки. Вместо этого мы создаем новую ячейку stationFrom, которая, с помощью оператора объединения потоков merge (приблизительный аналог на Rx — combineLatest), будет собирать значения двух потоков: пользовательского ввода (stationFromInput) и выбора станции (selectStationFrom).
Мы должны показывать список опций после того, как пользователь что-то вводит, и скрывать после того, как он выбрал одну из опций. За видимость списка опций будет отвечать ячейка optionsShown, которая будет принимать булевы значения в зависимости от изменения других ячеек. Это очень распостраненный паттерн, для которого существует синтаксический сахар — оператор toggle. Он устанавливает значение ячейки в true при любом изменении первого аргумента (потока), и в false — второго.
Добавим кнопку для очистки введенного текста.
const Tickets = withMrr({
$init: {
stationFromOptions: [],
stationFromInput: '',
},
stationFromOptions: [str => stations.filter(s => str.indexOf(a) === 0), 'stationFromInput'],
clearVal: [a => '', 'clear'],
stationFrom: ['merge', 'stationFromInput', 'selectStationFrom', 'clearVal'],
optionsShown: ['toggle', 'stationFromInput', 'selectStationFrom'],
}, (state, props, $) => {
return (<div>
<div>
Станция отправления:
<input onChange={ $('stationFromInput') } value={ state.stationFrom }/>
{ state.stationFrom && <button onClick={ $('clear') }>Х</button> }
</div>
{ state.optionsShown && <ul className="stationFromOptions">
{ state.stationFromOptions.map(s => <li onClick={ $('selectStationFrom', s) }>{ s }</li>) }
</ul> }
</div>);
});
Теперь наша ячейка stationFrom, отвечающая за содержимое текста в поле ввода, собирает свои значения не с двух, а с трех потоков. Этот код можно упростить. Конструкция mrr вида [*формула*, *… ячейки-аргументы*] аналогична S-выражениям в Lisp'е, и как и в Лиспе, вы можете произвольно вкладывать такие конструкции друг в друга.
Давайте избавимся от малополезной ячейки clearVal и сократим код:
stationFrom: ['merge', 'stationFromInput', 'selectStationFrom', [a => '', 'clear']],
Программы, написанные в императивном стиле, можна сравнить с плохо организованным коллективом, где все постоянно что-то приказывают друг другу (намекаю на вызовы методов и мутирующие изменения), при чем как руководители подчиненным, так и наоборот. Декларативные же программы похожи на противоположную утопическую картину: коллектив, где каждый четко знает, как он должен действовать в любой ситуации. В таком коллективе нет нужды в приказах, все просто находятся на своих местах и работают, реагируя на происходящее.
Вместо того, чтобы описывать всевозможные последствия какого-то события (читай — делать те или иные мутации), мы описываем все случаи, при которых данное событие может наступить, т.е. какие значение примет ячейка при тех или иных изменениях других ячеек. В нашем небольшом пока примере мы описали ячейку stationFrom и три ситуации, которые влияют на ее значение. Для привыкшего к императивному коду программиста такой подход может показаться непривычным (или даже «костылем», «извращением»). На самом деле он позволяет экономить усилия за счет краткости (и стабильности) кода, в чем мы убедимся на практике.
А что насчет асинхронности? Можно ли подтягивать список предложенных станций ajax'ом? Без проблем! В сущности, для mrr все равно, вернет ли функция значение или промис. При возврате промиса mrr дождется его resolv'а и «протолкнет» полученные данные в поток.
stationFromOptions: [str => fetch('/get_stations?str=' + str).then(res => res.toJSON()), 'stationFromInput'],
Это также означает, что вы можете использовать асинхронные функции в качестве формул. Более сложные случаи (обработка ошибок, статус промиса) мы рассмотрим позже.
Функционал для выбора станции отправления готов. Дублировать то же самое для станции прибытия нет смысла, стоит вынести это в отдельный компонент, который можно повторно использовать. Это будет обобщенный компонент инпута с автодополнением, поэтому мы переименуем поля и сделаем, чтобы функция получения подходящих вариантов задавалась в props'ах.
const OptionsInput = withMrr(props => ({
$init: {
options: [],
},
val: ['merge', 'valInput', 'selectOption', [a => '', 'clear']],
options: [props.getOptions, 'val'],
optionsShown: ['toggle', 'valInput', 'selectOption'],
}), (state, props, $) => <div>
<div>
<input onChange={ $('valInput') } value={ state.val } />
</div>
{ state.optionsShown && <ul className="options">
{
state.options.map(s => <li onClick={ $('selectOption', s) }>{ s }</li>)
}
</ul> }
{ state.val && <div className="clear" onClick={ $('clear') }>
X
</div> }
</div>)
Как видите, вы можете задать структуру ячеек mrr как функцию от props компонента (однако выполнится она лишь один раз — при инициализации, и не будет реагировать на изменение props).
Обмен данными между компонентами
Теперь подключим этот компонент в родительском компоненте и посмотрим, как mrr позволяет родственным компонентам обмениваться данными.
const getMatchedStations = str => fetch('/get_stations?str=' + str).then(res => res.toJSON());
const Tickets = withMrr({
stationTo: 'selectStationFrom/val',
stationFrom: 'selectStationTo/val',
}, (state, props, $, connectAs) => {
return (<div>
<OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } />
-
<OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } />
<input type="date" onChange={ $('date') } />
<button onClick={ $('searchTrains') }>Поиск</button>
</div>);
});
Чтобы связать родительский компонент с дочерним, мы должны передать ему параметры с помощью функции connectAs (четвёртый аргумент render-функции). При этом мы указываем имя, которое хотим дать дочернему компоненту. Присоединив таким образом компонент, по этому имени мы можем обращаться к его ячейкам. В данном случае, мы слушаем ячейки val. Возможно и обратное — слушать из дочернего компонента ячейки родительского.
Как видите, и здесь mrr следует декларативному подходу: не нужно никаких onChange колбэков, нам достаточно указать имя для дочернего компонента в функции connectAs, после чего мы получаем доступ к его ячейкам! При этом, опять же вследствии декларативности, угрозы вмешательства в работу другого компонента нет — мы не имеем возможности ничего в нем «изменить», мутировать, можно лишь «слушать» данные.
Сигналы и значения
Следующий этап — поиск подходящих поездов по выбранным параметрам. В императивном подходе мы бы наверняка написали некий обрабочик на отправку формы onSubmit, который бы инициировал дальнейшие действия — ajax запрос и отображение полученных результатов. Но, как вы помните, нам нельзя ничего «приказывать»! Мы можем только создать еще набор ячеек, производных от ячеек формы. Напишем еще один запрос.
const getTrains = (from, to, date) => fetch('/get_trains?from=' + from + '&to=' + to + '&date=' + date).then(res => res.toJSON());
const Tickets = withMrr({
stationFrom: 'selectStationFrom/val',
stationTo: 'selectStationTo/val',
results: [getTrains, 'stationFrom', 'stationTo', 'date', 'searchTrains'],
}, (state, props, $, connectAs) => {
return (<div>
<OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } />
-
<OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } />
<input type="date" onChange={ $('date') } />
<button onClick={ $('searchTrains') }>Поиск</button>
</div>);
});
Однако, такой код не будет работать как ожидалось. Калькуляция (пересчет значения ячейки) запускается при изменении любого из аргументов, поэтому запрос будет отправляться, например, сразу после выбора первой станции, а не только по клику на «Поиск». Нам нужно, с одной стороны, чтобы станции и дата передавались в аргументы формулы, но с другой стороны, не реагировать на их изменение. В mrr для этого существует элегантный механизм, называемый «пассивное слушание».
results: [getTrains, '-stationFrom', '-stationTo', '-date', 'searchTrains'],
Просто добавляем минус перед именем ячейки, и вуаля! Теперь results будет реагировать только на изменение ячейки searchTrains.
В этом случае ячейка searchTrains выступает как «ячейка-сигнал», а ячейки stationFrom и др. — как «ячейки-значения». Для ячейки-сигнала существенным является только момент, когда по ней «протекает» значние, при этом, какие именно данные это будут — все равно: это может быть просто true, «1» или что угодно (в нашем случае это будут объекты DOM Event). Для ячейки-значения важным есть именно ее значение, но при этом моменты ее изменения несущественны. Эти два типа ячеек не взаимоисключающи: многи ячейки являются и сигналами, и значениями. На уровне синтаксиса в mrr эти два вида ячеек никак не различаются, но само концептуальное понимание такого различия очень важно при написании реактивного кода.
Расщепление потоков
Запрос на поиск мест в поезде может занять некоторое время, поэтому мы должны показывать лоадер, а также реагировать в случае ошибки. Для этого дефолтного подхода с автоматическим резолвингом промисов уже мало.
const Tickets = withMrr({
$init: {
results: {},
}
stationFrom: 'selectStationFrom/val',
stationTo: 'selectStationTo/val',
searchQuery: [(from, to, date) => ({ from, to, date }), '-stationFrom', '-stationTo', '-date', 'searchTrains'],
results: ['nested', (cb, query) => {
cb({
loading: true,
error: null,
data: null
});
getTrains(query.from, query.to, query.date)
.then(res => cb('data', res))
.catch(err => cb('error', err))
.finally(() => cb('loading', false))
}, 'searchQuery'],
availableTrains: 'results.data',
}, (state, props, $, connectAs) => {
return (<div>
<div>
<OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } />
-
<OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } />
<input type="date" onChange={ $('date') } />
<button onClick={ $('searchTrains') }>Поиск</button>
</div>
<div>
{ state.results.loading && <div className="loading">Загрузка...</div> }
{ state.results.error && <div className="error">Произошла ошибка. Возможно, сервер перегружен. Попробуйте еще раз.</div> }
{ state.availableTrains && <div className="results">
{ state.availableTrains.map((train) => <div />) }
</div> }
</div>
</div>);
});
Оператор nested позвозяет «раскладывать» данные по подъячейкам, для этого первым аргументом в формулу передается callback, с помощью которого можно «протолкнуть» данные в подъячейку (одну или несколько). Теперь у нас есть отдельные потоки, которые отвечают за ошибку, статус промиса и за полученные данные. Оператор nested — очень мощный инструмент и один из немногих императивных в mrr (мы сами указываем, в какие ячейки класть данные). В то время как оператор merge объединяет несколько потоков в один, nested расщепляет поток на несколько подпотоков, таким образом являясь его противоположностью.
Приведенный пример является стандартным способом работы с промисами, в mrr он обобщен в виде оператора promise и позволяет сократить код:
results: ['promise', (query) => getTrains(query.from, query.to, query.date), 'searchQuery'],
// используем один из подпотоков
availableTrains: 'results.data',
Также оператор promise следит за тем, чтобы использовались результаты только самого последнего промиса.
Компонент для отображения наличных мест (откажемся для простоты от разных типов вагонов)
const TrainSeats = withMrr({
selectSeats: [(seatsNumber, { id }) => new Array(Number(seatsNumber)).fill(true).map(() => ({ trainId: id })), '-seatsNumber', '-$props', 'select'],
seatsNumber: [() => 0, 'selectSeats'],
}, (state, props, $) => <div className="train">
Поезд №{ props.num } { props.from } - { props.to }. Количество свободных мест: { props.seats || 0 }
{ props.seats && <div>
Выберите необходимое Вам количество мест:
<input type="number" onChange={ $('seatsNumber') } value={ state.seatsNumber || 0 } max={ props.seats } />
<button onClick={ $('select') }>Выбрать</button>
</div> }
</div>);
Чтобы обращаться к props в формуле, можно подписаться на специальную ячейку $props.
const Tickets = withMrr({
...
selectedSeats: '*/selectSeats',
}, (state, props, $, connectAs) => {
...
<div className="results">
{ state.availableTrains.map((train, i) => <TrainSeats key={i} {...train} {...connectAs('train' + i)}/>) }
</div>
}
Мы опять используем пассивное слушание чтобы подхватить количество выбранных мест при нажатии на кнопку «Выбрать». Каждый дочерний компонент мы связываем с родительским с помощью функции connectAs. Пользователь может выбрать места в любом из предложенных поездов, поэтому мы слушаем изменения во всех дочерних компонентах с помощью маски "*".
Но вот незадача: пользователь может добавить места сначала в одном поезде, потом в другом, так что новые данные перетрут предыдущие. Как «аккумулировать» данные потока? Для этого существует оператор closure, который вместе с nested и funnel составляет основу mrr (все остальные — не более чем синтаксический сахар на основе этих трех).
selectedSeats: ['closure', () => {
let seats = [];
// эта функция станет формулой
return selectedSeats => {
seats = [...seats, selectedSeats];
return seats;
}
}, '*/selectSeats'],
При использовании closure сначала (на componentDidMount) создается замыкание, которое возвращает формулу. Она таким образом имеет доступ к переменным замыкания. Это позволяет сохранять данные между вызовами безопасным способом — не скатываясь в пучину глобальных переменных и shared mutable state. Таким образом, closure позволяет реализовать функциональность таких операторов Rx, как scan и прочие. Однако этот способ хорош для сложных случаев. Если же нам нужно только сохранять значение одной переменной, мы можем просто использовать ссылку на предыдущее значение ячейки с помощью специального имени "^":
selectedSeats: [(seats, prev) => [...seats, ...prev], '*/selectSeats', '^']
Теперь пользователь должен ввести имя и фамилию для каждого выбранного билета.
const SeatDetails = withMrr({}, (state, props, $) => {
return (<div>Поезд { props.trainId }
<input name="name" value={ props.name } onChange={ $('setDetails', e => ['name', e.target.value, props.i]) } />
<input name="surname" value={ props.surname } onChange={ $('setDetails', e => ['surname', e.target.value, props.i]) }/>
<a href="#" onClick={ $('removeSeat', props.i) }>X</a>
</div>);
})
const Tickets = withMrr({
$init: {
results: {},
selectedSeats: [],
}
stationFrom: 'selectStationFrom/val',
stationTo: 'selectStationTo/val',
searchQuery: [(from, to, date) => ({ from, to, date }), '-stationFrom', '-stationTo', '-date', 'searchTrains'],
results: ['promise', (query) => getTrains(query.from, query.to, query.date), 'searchQuery'],
availableTrains: 'results.data',
selectedSeats: [(seats, prev) => [...seats, ...prev], '*/selectSeats', '^']
}, (state, props, $, connectAs) => {
return (<div>
<div>
<OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } />
-
<OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } />
<input type="date" onChange={ $('date') } />
<button onClick={ $('searchTrains') }>Поиск</button>
</div>
<div>
{ state.results.loading && <div className="loading">Загрузка...</div> }
{ state.results.error && <div className="error">Произошла ошибка. Возможно, сервер перегружен. Попробуйте еще раз.</div> }
{ state.availableTrains && <div className="results">
{ state.availableTrains.map((train, i) => <TrainSeats key={i} {...train} {...connectAs('train' + i)}/>) }
</div> }
{ state.selectedSeats.map((seat, i) => <SeatDetails key={i} i={i} { ...seat } {...connectAs('seat' + i)}/>) }
</div>
</div>);
});
Ячейка selectedSeats содержит массив выбранных мест. По мере того, как пользователь вводит имя и фамилию к каждому билету, мы должны изменять данные в соотвествующих элементах массива.
selectedSeats: [(seats, details, prev) => {
// ???
}, '*/selectSeats', '*/setDetails', '^']
Стандартный подход нам не подойдет: в формуле мы должны знать, какая именно ячейка изменилась и реагировать соответствующе. Нам поможет одна из форм оператора merge.
selectedSeats: ['merge', {
'*/selectSeats': (seats, prev) => {
return [...prev, ...seats];
},
'*/setDetails': ([field, value, i], prev) => {
prev[i][field] = value;
return prev;
},
'*/removeSeat': (i, prev) => {
prev.splice(i, 1);
return prev;
},
}, '^'/*, здесь также могут быть любые другие аргументы*/],
Это немного напоминает редьюсеры Redux'а, но с более гибким и мощным синтаксисом. И можно не бояться мутировать массив, ведь контроль над ним имеет только формула одной ячейки, соответственно параллельные изменения исключены (а вот мутировать массивы, которые передаются в качестве аргументов, конечно же не стоит).
Реактивные коллекции
Паттерн, когда ячейка хранит в себе и изменят массив, очень распостранен. Все операции с массивом при этом бывают трех типов: вставка, изменение, удаление. Чтобы описать это, существует элегантный оператор "coll". Используем его чтобы упростить вычисление selectedSeats.
Было:
selectedSeats: ['merge', {
'*/selectSeats': (seats, prev) => {
return [...prev, ...seats];
},
'*/setDetails': ([field, value, i], prev) => {
prev[i][field] = value;
return prev;
},
'*/removeSeat': (i, prev) => {
prev.splice(i, 1);
return prev;
},
'addToCart': () => [],
}, '^']
стало:
selectedSeats: ['coll', {
create: '*/selectSeats',
update: '*/setDetails',
delete: ['merge', '*/removeSeat', [() => ({}), 'addToCart']]
}]
при этом формат данных в потоке setDetails нужно немного изменить:
<input name="name" onChange={ $('setDetails', e => [{ name: e.target.value }, props.i]) } />
<input name="surname" onChange={ $('setDetails', e => [{ surname: e.target.value }, props.i]) }/>
Используя оператор coll, мы описываем три потока, которые будут влиять на наш массив. При этом поток create должен содержать сами элементы, которые должны быть добавлены в массив (обычно — объекты). Поток delete принимает либо индексы элементов, которые нужно удалить (как в '*/removeSeat'), так и маски. Маска {} удалит все элементы, а, к примеру, маска { name: 'Carl' } удалила бы все элементы с именем Carl. Поток update принимает пары значений: изменение, которое нужно сделать с элементом (маска либо функция), и индекс или маску элементов, которые нужно изменить. Например, [{ surname: 'Johnson' }, {}] установит фамилию Johnson всем элементам массива.
Оператор coll использует что-то вроде внутреннего языка запросов, позволяя упростить работу с коллекциями и сделать ее более декларативной.
Полный код нашего приложения на JsFiddle.
Мы ознакомились практически со всем необходимым базовым функционалом mrr. Довольно существенная тема, которая осталась за бортом — глобальное управление состоянием, возможно она будет рассмотрена в следующих статьях. Но уже сейчас вы можете начать использовать mrr для управления состоянием внутри компонента или группы родственных компонентов.
Выводы
В чем сила mrr?
mrr позволяет писать приложения на React в функционально-реактивном стиле (mrr можно расшифровать как Make React Reactive). mrr очень выразителен — вы тратите меньше времени на написание строчек кода.
mrr предоставляет небольшой набор базовых абстракций, которого достаточно для всех случаев — в этой статье описаны практически все основные фичи и приемы mrr. Также есть инструменты для расширения этого базового набора (возможность создавать кастомные операторы). Вы сможете писать красивый декларативный код, не читая сотни страниц мануала и даже не изучая теоретические глубины функционального программирования — врядли вам придется использовать, скажем, монады, т.к. mrr сам представляет собой гигантскую монаду, отделяющую чистые вычисления от мутаций состояния.
В то время как в других библиотеках зачастую соседствуют разнородные подходы (императивный с помощью методов и декларативный с помощью реактивных биндингов), из которых программист произвольно смешивает «салат», в mrr существует единая базовая сущность — поток, что способствует гомогенности и единообразию кода. Комфорт, удобство, простота, экономия времени программиста — основные преимущества mrr (отсюда еще одна расшифровка mrr как «мр-р-р», то есть мурчание удовлетворенного жизнью кота).
Каковы минусы?
Программирование «строками» имеет как свои преимущества, так и недостатки. У вас не будет работать автокомплит имени ячейки, а также поиск места, где она определена. С другой стороны, в mrr всегда есть одно и только одно место, где определяется поведение ячейки, и его несложно найти простым текстовым поиском, в то время как поиск места, где определяется значение поля Redux стора, или тем более поля state при использовании нативного setState, может быть более долгим.
Кому это может быть интересно?
В первую очередь, адептам функционального программирования — людям, для которых преимущество декларативного подхода очевидно. Конечно, уже существуют кошерные решения на ClojureScript, но все же они остаются нишевым продуктом, в то время как React правит бал. Если в вашем проекте уже используется Redux, вы можете начать использовать mrr для управления локальным состоянием, и в перспективе перейти к глобальному. Даже если вы не планируете использование новых технологий в данный момент, вы можете разобраться с mrr чтобы «размять мозг», взглянув на привычные задачи в новом свете, ведь mrr существенно отличается от распостраненных библиотек управления состоянием.
Это уже можно использовать?
В принципе, да :) Библиотека молодая, пока что активно использовалась на нескольких проектах, но API базового функционала уже устоялось, сейчас работа ведется преимущественно над разными примочками (синтаксический сахар), призванными еще больше ускорить и облегчить разработку. К слову, в самих принципах mrr нет ничего специфично React'овского, его возможно адаптировать для использования с любой компонетной библиотекой (React был выбран в силу отсутствия у него встроенной реактивности или общепринятой библиотеки для этого).
Спасибо за внимание, буду благодарен за отзывы и конструктивную критику!
Автор: mikolalex
