Что я понял, благодаря неуспехам. Реджинальд Брейдвайт

Эта книга больше не о программировании, а скорее об отношении к работе и индустрии в целом. Что делать, чего не делать, почему так, и к чему приводят неправильные решения.

Онлайн‑версию в оригинале можно прочитать бесплатно. Она довольно короткая, я осилил за вечер.

Глава 1. Что я понял, благодаря неуспехам

Разработка проекта может провалиться, если хотя бы одна из составляющих хромает:

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

Люди

Слабые команды проигрывают. Признак слабой команды: если вы бы собрались уйти с работы и не захотели забрать с собой никого из коллег, команда слабая.

Слабые продукт‑оунеры тоже проигрывают. Признавать, что у проекта проблемы и пора вносить изменения — сложно и страшно, но необходимо.

Внешние навязанные ограничения (государственные, например) как правило вредят.

Действие

Получать обратную связь надо быстро — fail fast! Чем раньше узнаете, что у вас проблемы, тем проще найти решение. Работает как в отношении кода, так и продукта в целом.

Детали

Детали и спорные решения в проекте должны быть всегда видны всем. Перестать следить за деталями — начать хоронить проект.

Расписание

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

Сила

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

История

Гипотеза, основанная на действиях из прошлого, может не сработать в будущем.

«Если бы мы больше времени уделили планированию, то спланировали бы лучше; так было в прошлом проекте» — вовсе не факт.

Уметь заканчивать

Уходить из проекта тоже иногда полезно. Игра в героя, который тащит на себе всё, может плохо сказаться как на здоровье «героя», так и на здоровье проекта. Иногда вам не обязательно заканчивать то, что начали вы. Иногда вам не обязательно заканчивать то, что начали другие.

Глава 2. Дизайн софта

Строить лучше

Чтобы понять детали проекта, надо узнать, чем он отличается ото всех других. Самые важные архитектурные решения опираются именно на отличия проекта от других.

Лучшая архитектура

Архитектура тем лучше, чем точнее и детальнее описывает конкретно этот проект. Она должна быть компактной, но детально описывать особенности.

Глава 3. Теория, которая подтверждает наблюдения

Теория D, теория P, и почему они важны

Если мы верим в теорию D (deterministic — что процесс можно описать полностью, и если что‑то не сходится, то у нас просто не хватает данных), то мы верим, что проект можно спланировать заранее и полностью.

Если мы верим в теорию P (probabilistic — что предсказать полностью ничего нельзя, а только какие‑то части и только с какой‑то точностью), то мы верим, что планировать следует только какие‑то части проекта, и когда что‑то идёт не так, нам надо добавить в план новую информацию, чтобы скорректировать его.

Вера определяет поведение

Адепты теории D верят, что:

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

Адепты теории P верят, что:

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

Глава 5. Проект‑менеджмент как рынок с информацией

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

Проект похож на рынок, где какая‑то информация ценится там, где её не хватает. Задача менеджеров в том, чтобы уметь отделять ценную информацию (которая поможет предсказать исход проекта или его части) от неценной; уметь «покупать» её у разработчиков и «продавать» её руководству или инвесторам.

Глава 6. Кирпичи

Софт делается не из кирпичей

Аналогия с кирпичами опасна. Кирпичи — слишком простые. Если понятно, как работать с одним кирпичом, понятно, как работать с остальными. В софте не так. Мало того, что там не всегда понятно, как обращаться с «кирпичами», там ещё и непонятно, сколько их надо, чтобы собрать проект.

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

Разработку трудно параллелить

«Кирпичи» из которых состоит софт, связаны друг с другом в каком‑либо виде. Чтобы разрабатывать их параллельно, требуется изначально продумать, как они должны взаимодействовать — что не всегда получается хорошо.

Если добавлять людей в проект, чтобы распараллелить разработку на поздних стадиях (когда какая‑то часть уже написана), то продуктивность даже упадёт.

Вторая беда с аналогией про кирпичи в том, что она позволяет думать, будто можно оценить прогресс по количеству использованных кирпичей. Но софт — трансфинитивен (простите, я не смог перевести иначе).

Важную роль также играет и «куда положить какой кирпич» и «как его соединить с другими». Одна ошибка может откатить отметку прогресса сильно назад.

Третье отличие от кирпичей: с развитием проекта меняются клиентские требования, поэтому прогресс придётся пересчитывать постоянно.

Глава 7. Цикл «попытка‑провал»

Весь смысл этого цикла в том, чтобы создать план, но заранее понимать, что план не выдержит столкновения с реальностью. Поэтому лучше напороться на проблемы раньше (fail fast!).

Обратная связь

Есть ошибка, при которой софт разрабатывается инкрементами вместо итераций.

Инкремент — часть софта, которая сама по себе закончена, но не несёт ценности для бизнеса. Итерация — законченная часть, которая несёт ценность бизнесу.

Чтобы обратная связь работала, это должна быть обратная связь от настоящих пользователей. Единственный способ получать такую обратную связь и получать её быстро — итеративная разработка.

Глава 8. Облысение софта

Технический долг приводит к нерабочему продукту.

Глава 9. Мышиная ловушка

Архитектура мышиной ловушки — набор несовместимых компонентов, используемых не по их прямому назначению, непонятно как связанных между собой хрупкими костылями.

Глава 10. Утиное программирование

Это менеджерский антипаттерн; мнение, что всё, что не связано с программистами, языками программирования или инструментами — программированием не является.

Глава 11. Не получается найти хороших продажников

Мы верим в свой продукт. Но продажникам надо убедить потребителей, что у тех есть потребность, а наш продукт может её удовлетворить и что эту потребность надо закрыть сейчас. Они готовы взять риски, но только за то, что могут контролировать.

Эту книгу дополнят

Некоторые другие книги о программировании:

• Чистый код. Роберт Мартин
• Чистая архитектура. Роберт Мартин
• Читаемый код или программирование как искусство. Б. Дастин, Ф. Трэвор

И вообще:

• Антихрупкость. Нассим Талеб
• Чёрный лебедь. Нассим Талеб
• Взлом маркетинга. Фил Барден

Потерянная абстракция

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

У нас будет класс Reader, который представляет читателя. Он принимает данные о пользователе и полке, привязанной к нему.

Ещё у нас будет код, который использует экземпляр этого класса в условии внизу. В нём мы будем проверять, есть ли определённая книга на полке у этого читателя и может ли он её прочесть.

Вопрос: что не так с этим условием в конце?

class Reader {
  constructor(user, shelf) {
    this.user = user
    this.shelf = shelf
  }

  getBooksFromShelf = () =>
    this.shelf.getBooks()
}

const reader = new Reader(
  someUserData, 
  someBookShelfData)

// вот тут проблема ↓
if (reader.getBooksFromShelf().contains(book.id)) {
  // ...
}

На первый взгляд всё, вроде, адекватно, но можно сделать лучше.

Смысл вместо реализации

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

Но как только мы…

// заменим условие на метод-предикат canRead,
// в который вынесем всю техническую реализацию...
if (reader.canRead(book)) {
  // ...
}

class Reader {
  // ...
  canRead = book => 
    this.getBooksFromShelf().contains(book.id)
}

…код станет гораздо понятнее.

Говорящий метод

Изменилось мало: мы добавили метод, который скрывает внутри себя то, что раньше находилось в условии. Но благодаря ему мы теперь не говорим, как мы хотим что‑то сделать; мы говорим, что мы хотим сделать.

Мы начинаем описывать взаимодействие между сущностями через процессы из предметной области. Такое описание облегчает чтение кода, потому что выражает намерение — чего мы хотим добиться в результате.

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

В книге “97 Things Every Programmer Should Know” есть глава “Code in the Language of Domain”. Она как раз описывает подобные случаи.

Ссылочки, ссылочки, ссылочки

Ютуб, книга, два конспекта и статья:

• Kevlin Henney. Seven Ineffective Coding Habits of Many Programmers
• 97 Things Every Programmer Should Know
• Чистый код. Роберт Мартин
• Читаемый код или программирование как искусство. Б. Дастин, Ф. Трэвор
• Фасад

От Редакса к хукам

В Реакте в версии 16.7.0 появились Hooks (дальше по тексту — хуки). Это API, которое позволяет использовать локальный стейт без использования классов. И среди них есть один, который, как мне кажется, может заменить собой Редакс.

В этой статье я предполагаю, что вы знаете разницу между функциональными компонентами и классами, в курсе о локальном стейте и жизненном цикле компонентов и о том, как работает Редакс. Без этого вникнуть будет трудно, но всё в одну статью я бы не уместил, так что вот ¯\_(ツ)_/¯

Что за хуки?

Раньше, чтобы использовать стейт в компоненте, приходилось писать класс. Хуки позволяют использовать стейт в функциональных компонентах без применения классов.

Например, здесь мы используем хук useState, чтобы создать и использовать переменную counter:

import React, {useState} from 'react'
const SimpleComponent = () => {
  const [counter, setCounter] = useState(0)
  // в первый раз значение counter будет равно тому, что мы передаём в useState
  // затем — тому, что мы установим через setCounter
  return <div>{counter}</div>
}

useState возвращает кортеж из значения и функции, которая будет это значение обновлять.

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

useReducer

useReducer — это хук, который по принципу работы схож с редьюсерами из Редакса.

const App = () => {
  const [state, dispatch] = useReducer(reducer, initialState)
  // initialState — начальное состояние
  // reducer — функция, которая принимает state и action 
  //           и обрабатывает изменение состояния
  //
  // state — текущее состояние
  // dispatch — функция, которая будет дёргать экшены, 
  //            чтобы обновить состояние

  return <div>Hello world</div>
}

По принципу работы это и есть Редакс. Проблема только в том, что переменные state и dispatch находятся внутри области видимости функции App, а значит использовать этот редьюсер в других компонентах у нас не получится.

…Если только мы не используем контекст.

Context API

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

Это работает, но если дерево большое, то и пробрасывать пропсы приходится через каждый уровень вложенности. Возникает так называемый prop drilling. Схематично это выглядит, как на картинке слева:

Редакс помимо работы с состоянием решал и эту проблему тоже. С ним мы создаём лишь одно хранилище, к которому может обращаться любой компонент. Таким образом нам не требуется пробрасывать свойства через всё дерево.

Ту же проблему решает и контекст в Реакте. Мы создаём контекст, через провайдер указываем, что именно нужно хранить и передавать, а через консьюмер — в каком компоненте эти значения забирать и использовать:

import {createContext} from 'react'
// создаём контекст
const StoreContext = createContext()

const App = () => (
  // через провайдер в свойстве value указываем значение,
  // которое нам надо хранить и как-то использовать в других компонентах
  <StoreContext.Provider value={{meaningOfLife: 42}}>
    <OtherComponent />
  </StoreContext.Provider>
)

const OtherComponent = () => {
  <StoreContext.Consumer>
    // через консьюмер получаем доступ к значению
    {({meaningOfLife}) => (
      <div>{meaningOfLife}</div>
    )}
  </StoreContext.Consumer>
}

Вызывать консьюмер можно где угодно, и это позволяет делить состояние между компонентами. И тут возникает мысль, нельзя ли заменить Редакс на смесь хуков и контекста. Ну и эт, вроде, можно.

Пример

Я написал простенькое приложение с использованием Редакса и с использованием контекста и хуков. Это счётчик, значение которого можно менять кнопками, либо меняя значение в инпуте, а также обнулять его нажатием на кнопку из другого компонента.

По структуре оно будет состоять из корневого компонента App, компонента формы Form и ещё одного компонента с кнопкой внизу Display. Схематично можно изобразить так:

Компоненты Form и Display зависят от хранилища, в котором содержится состояние приложения. Все события кнопок и инпута вызывают экшены, которые будут обновлять хранилище.

• Пример с Редаксом.
• Пример с хуками и контекстом.
• Исходники для самых нетерпеливых.

С использованием Редакса

Вначале создадим хранилище и редьюсер, который будет заниматься его обновлением:

// reducers.js
import {combineReducers} from 'redux'

const app = (state, action) => {
  switch(action.type) {
    case 'PLUS':
      return {...state, counter: state.counter + 1}

    case 'MINUS':
      return {...state, counter: state.counter - 1}

    case 'MAGIC':
      return {...state, counter: Math.floor(Math.random() * 100)}

    case 'CHANGE':
      return {...state, counter: +action.value}

    case 'RESET':
      return {...initialState}

    default:
      return state
  }
}

export default combineReducers({ app })

// index.js
import {createStore} from 'redux'
import rootReducer from './reducers'
import App from './App'

// создаём хранилище
const store = createStore(rootReducer)

// используем через провайдер
render(
  <Provider store={store}><App /></Provider>,
  document.getElementById('app'))

Дальше создадим экшены, которые будут вызываться событиями кнопок и инпута:

// actions.js
export const plus = () => ({ type: 'PLUS' })
export const minus = () => ({ type: 'MINUS' })
export const magic = () => ({ type: 'MAGIC' })
export const reset = () => ({ type: 'RESET' })
export const change = e => ({ 
  value: e.target.value,
  type: 'CHANGE', 
})

Чтобы привязать какой‑то компонент к хранилищу, используем connect:

import {connect} from 'react-redux'
import {reset} from './actions'

// app — часть хранилища;
// reset — экшен;
// всё это мы привязали через connect перед экспортом ниже
const Display = ({app, reset}) => {
  const {counter} = app

  return <footer>
    <p>Another component knows that counter equals to {counter} as well!</p>
    <p>
      It even can 
      <button onClick={reset}>reset the coutner</button>
    </p>
  </footer>
}

// мапим свойства из хранилища и экшены
// на пропсы компонента
export default connect(
  state => ({ app: state.app }),
  {reset}
)(Display)

В результате приложение будет работать так.

Контекст + хуки

Теперь напишем то же самое без использования Редакса. Используем useReducer:

// store.js
export const initialState = {counter: 0}

// редьюсер точно такой же, как в прошлый раз 
export const reducer = (state, action) => {
  switch(action.type) {
    // ...
  }
}

// index.js
import {reducer, initialState} from './store'

const App = () => {
  // создаём в корневом компоненте хранилище
  // и функцию для его обновления
  const [state, dispatch] = useReducer(reducer, initialState)
  return <div></div>
}

Чтобы пробросить значения из хранилища компонентам, воспользуемся контекстом:

// context.js
import {createContext} from 'react'
export const StoreContext = createContext()

// index.js
import {reducer, initialState} from './store'
// импортируем созданный контекст
import {StoreContext} from './context'

const App = () => {
  const [state, dispatch] = useReducer(reducer, initialState)

  // используем провайдер, чтобы передать в контекст 
  // хранилище и функцию для обновления
  return (
    <StoreContext.Provider value={{dispatch, state}}>
      <Form />
      <Display />
    </StoreContext.Provider>
  )
}

export default App

Чтобы привязать какой‑то компонент, используем консьюмер:

import React from 'react'
// импортируем контекст 
import {StoreContext} from './context'
// экшены точно такие же, как в прошлый раз
import {reset} from './actions'

const Display = () => (
  // получаем доступ к тому, что хранится в контексте
  <StoreContext.Consumer>
    // в нашем случае — state и dispatch
    {({state, dispatch}) => (
      <footer>
        // используем state, чтобы вывести значение счётчика
        <p>{state.counter}</p>
        // используем dispatch, чтобы дёрнуть экшен
        <button onClick={() => dispatch(reset())}>reset</button>
      </footer>
    )}
  </StoreContext.Consumer>
)

export default Display

А ещё можно сделать код чище, заменив консьюмер на useContext:

import React, {useContext} from 'react'
import {StoreContext} from './context'
import {reset} from './actions'

const Display = () => {
  // вызываем useContext, передавая аргументом нужный контекст
  const {state, dispatch} = useContext(StoreContext)

  return (
    // убираем консьюмер
    <footer>
      <p>{state.counter}</p>
      <button onClick={() => dispatch(reset())}>reset</button>
    </footer>
  )
}

export default Display

И работает оно точно так же.

А чо по весу и перформансу?

Я не удивился, когда бандл ужался на 12 кБ: с Редаксом — 166, без него — 154. Это логично, меньше зависимостей — меньше вес.

А вот прирост в скорости обработки экшенов и отрисовки меня слегка удивил. Я проводил измерения с помощью console.time и performance.measure. Средние значения за 100 итераций вышли такими:

Минусы

Вызов экшенов стал чуть более многословным из‑за прямого использования dispatch. И если работать с контекстом без useContext, придётся использовать паттерн render‑prop, из‑за чего может подняться щит‑сторм ¯\_(ツ)_/¯

Но если серьёзно, хуки — пока что в стадии RFC, и возможно многое поменяется. Поэтому переписывать свои приложения на них не советует даже Дэн Абрамов. То есть это экспериментальная фигня.

Хотя выглядит всё равно заманчиво :–)

Ссылки

Документация

• Context API
• Hooks API
• useReducer
• useContext
• Hooks rules

Доклады

• React Today and Tomorrow
• 90% Cleaner React With Hooks

Статьи со сравнениями

• Everything You Need to Know About Context API
• Context API vs Redux
• Redux против React Context API

Измерения перформанса

• Measuring Performance with console.time
• Performance.measure
• Measuring Functions Performance

Исходники и примеры

• Гитхаб
• Приложение на Редаксе
• Приложение на хуках с контекстом

Грязная архитектура

Так сложилось, что во фронтенде об архитектуре задумываются не так часто, как стоило бы. Не то чтобы я был исключением, но мне это принесло на проекте проблемы, которые я сейчас разгребаю. Мне хочется, чтобы на мои грабли наступило как можно меньше разработчиков, отсюда — этот пост.

Проблема

Современный фронтенд — сложный. Много бизнес‑логики перекочевало из сервера в браузер. Сингл‑пейджи, большие приложения со сложной структурой, логикой и прочим — этим добром сейчас никого не удивишь.

Но кроме сложной логики у фронта куча сопутствующих проблем типа манипуляций с ДОМ, ломающимися стилями, всеми ненавистным и никем не понятым каскадом и другими ништяками веб‑разработки.

Ну и сроки, да. Они всегда горят. Разработчики стали той собакой, у которой «всё хорошо»:

Появились инструменты для решения проблем с рутиной. Манипуляции с ДОМ, запросы к серверу, обработка состояния, хранение данных — со всем этим нам стали помогать библиотеки и фреймворки.

Инструменты — это суперздорово, потому что они снимают с разработчиков нагрузку и позволяют сосредоточиться на бизнес‑логике приложения. Хорошо же? Да, хорошо, но только это чё‑то не работает, как задумано.

Мы всё ещё не уделяем достаточно внимания бизнес‑логике, а упарываемся по модным библиотекам (привет, Реакт!) и фреймворкам (привет, Ангуляр!). И спорим, что лучше, что хуже, на чём приложения моднее.

Нам кажется, что инструменты предлагают решения для структуры проекта. Но фреймворк или библиотека не должны диктовать ни структуру проекта, ни правила общения компонентов системы друг с другом, ни что‑либо ещё.

Инструмент не должен вообще ничего вам диктовать

Инструмент должен делать работу, для которой его придумали. Молоток не говорит плотнику, как ему сколачивать детали друг с другом, потому что плотник использует молоток как подручное средство.

Не должно быть никаких «Реакт‑приложений» или «Редакс‑приложений», потому что это инструменты. Реакт должен рисовать пиксели на экране. Редакс должен работать с состоянием. Всё.

А как надо, умник?

Мартин в «Чистой архитектуре» пишет, что ядром любой программной системы должны быть бизнес‑правила, потому что любая программная система — это решение бизнес‑задач.

Бизнес‑правила — скелет, вокруг которого наворачивается мясо

Мясо — всё, что заточено под проект: фреймворк, веб‑натив‑гибрид, ватевер. И бизнес‑правила по‑хорошему никак не должны от этого зависеть.

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

Хорошая архитектура по Мартину это луковица из нескольких слоёв. Ядро — сущности, объекты, которые содержат критичные для бизнеса правила и данные для их работы. На втором уровне — юзкейсы, модели общения между пользователем и сущностями. Фреймворки находятся на самом внешнем слое. 

При грамотно спроектированной архитектуре приложения, вы можете выкинуть Реакт и переписать всё за вечер на Вью. И приложение не поломается, потому что интерфейс зависит от бизнес‑правил, а не наоборот.

А как же фигак‑фигак и в продакшен?

Ну да, есть такое. Сроки горят, прототипы нинужны, на тесты нет времени. Плавали, знаем.

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

Кроме того, что такую систему было бы проще развивать и масштабировать, её было бы гораздо проще тестировать. Когда ядро ни от чего не зависит, то и фейков для тестирования требуется меньше. А про раздельный деплой ядра и всего остального я вообще молчу.

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

Ну и как тогда начать проект?

Вполне логичный вопрос. Какую структуру выбрать, куда класть файлы, как их называть, и всё такое. Если раньше фреймворк приносил с собой готовое решение, то теперь надо его придумать самим.

Но за меня на этот вопрос уже ответил Дэн Абрамов в твитере:

• о структуре проекта
• «лучшей» структуре проекта
• процессе разработки

Всё зависит от бизнес‑правил. Проектируйте, опираясь на них

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

А когда начнёте писать код, старайтесь откладывать решение о выборе инструментов до самого последнего момента. Пишите так, чтобы к ядру можно было прикрутить что угодно. Всё должно зависеть от бизнес‑правил, не наоборот. Вот тогда приложение действительно будет масштабируемым и тестируемым.

Ссылки

Конспект «Чистой архитектуры»

• часть 1
• часть 2
• часть 3

Дэн Абрамов в твитере

• о структуре проекта
• «лучшей» структуре проекта
• процессе разработки

«Кликни меня!» на RxJS

На прошлых выходных мне надо было поковырять RxJS, и я попробовал написать игру с кнопкой, которая убегает из‑под курсора. В этом посте расскажу, что и как именно я использовал при написании и разберу по шагам процесс.

Если вы уже работали с этой технологией, скорее всего, ничего нового не узнаете. Пост ориентирован на таких как я — которым из RxJS знаком только JS.

Игру будем писать на Тайпскрипте. Отличий от обычного JS будет немного, но всё же стоит глянуть документацию по нему, чтобы знать, как объявляются типы переменных и возвращаемых из функции значений.

Почему Тайпскрипт

Мне давно хотелось его распробовать, а RxJS написан как раз на нём. Я подумал, почему бы не добавить себе ограничений и головной боли, ну и вот ¯\_(ツ)_/¯

Что такое RxJS

RxJS — это имплементация ReactiveX для JS.
ReactiveX в свою очередь, если верить главной их сайта, — это АПИ для асинхронной работы с наблюдаемыми потоками. Я тож не сразу въехал, будем разбираться по порядку.

Если выражаться примитивно, поток — это последовательность чего‑то: событий, данных, преобразований и т. д. Представьте себе чатик, в котором вы с кем‑то переписываетесь. Последовательность сообщений в нём — это и есть поток.

Поток наблюдаемый, если мы можем на него подписаться — объявить функцию, которая будет обрабатывать каждый новый элемент. Чатик — это наблюдаемый поток, если мы сидим и читаем каждое новое сообщение.

Польза потоков в том, что они дают возможность не обрабатывать, например, события по одному, а объединить их и работать сразу с набором событий.

Наблюдатель и наблюдаемый

ReactiveX в основе использует шаблон «Наблюдатель». Два основных понятия, которые нам понадобятся — это observer (наблюдатель) и observable (наблюдаемый).

Наблюдаемым будет поток: он отправляет элементы из какого‑то источника по одному за раз. Это можно представить как ручей, по которому плывут кораблики‑элементы.

Наблюдатель — это объект, который знает, что с элементами из потока надо делать и как их обработать. Это можно представить как ребёнка, который хочет кораблики собрать и унести домой.

Наблюдатель связан с наблюдаемым через подписку (subscribe) — функцию, которая передаёт элементы от наблюдаемого наблюдателю. Это похоже на сетку, которая ловит проплывающие кораблики. Когда новый кораблик попадает в сетку, ребёнок его замечает и может забрать себе.

Наблюдаемый поток знает, как сообщить:

• что появился новый элемент;
• произошла ошибка;
• элементы закончились.

На всё это наблюдатель может как‑то реагировать.

Диаграммы

Чтобы понять концепцию потоков лучше, документация к RxJS предлагает так называемые marble diagrams. На них изображены шарики, которые как бы нанизаны на нитку.

Эти шарики — это элементы в потоке. Нитка — это линия времени, направленная слева направо. Если элемент стоит левее, значит он появился раньше.

(Было бы конечно круче это всё показывать анимацией: ну типа элементы один за другим падают вниз, проходят преобразование, падают дальше.)

Применимо к игре

Чтобы написать игру, надо определить, какие события мы собираемся обрабатывать и что мы с ними хотим делать.

Мы будем отслеживать движение мыши и проверять, где находится курсор. Если он находится в пределах 15 пикселей от кнопки, то будем перерисовывать кнопку.

Если чуть ближе к коду, то у нас будет поток из событий перемещения мыши. Мы их будем чистить и оставлять только координаты {x, y}. Затем будем фильтровать координаты, проверяя находится ли курсор достаточно близко от кнопки:

Начинаем пилить

В RxJS поток можно сделать из чего угодно: из массива, промиса, событий в браузере. Например, из массива его можно сделать с помощью оператора from:

import {from} from 'rxjs'

// выталкивает по одному элементу из массива, пока они не закончатся
const arraySource = from([1, 2, 3, 4, 5])

Источником для нашего потока будет событие движения мыши по экрану. Чтобы создать источник из браузерного события, мы будем использовать fromEvent:

import {fromEvent} from 'rxjs/observable/fromEvent'

const source = fromEvent(document, 'mousemove')

Теперь браузерное событие mousemove будет отслеживаться в пределах document, и на каждое перемещение будет появляться новый элемент в source.

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

Операторы

Операторы — это функции, которыми можно преобразовывать элементы после того, как observable их отправил.

Чтобы применить несколько преобразований по очереди, нам потребуется pipe. Это метод, который занимается композицией операторов, то есть применяет их по порядку.

import {map, filter} from 'rxjs/operators'

// ...

const observable = source.pipe(
  map(...),
  filter(...)
)

Оператор map нам нужен, чтобы применить к каждому элементу какую‑то функцию.

Мы хотим извлечь из данных о каждом событии координаты мыши на экране. Поэтому в map мы передадим функцию, которая будет доставать эти данные и возвращать объект.

map((event: MouseEvent): MouseCoords => ({ x: event.x, y: event.y }))

MouseCoords — это тип данных, который мы создадим для работы с координатами. Он будет представлять из себя объект с полями {x, y}. Создавать новый тип необязательно, но так понятнее, с чем мы работаем.

type MouseCoords = {
  x: number,
  y: number,
}

// ...

map((event: MouseEvent): MouseCoords => ({ x: event.x, y: event.y }))

Оператор filter будет выбирать события, которые нам подходят.

Событие нам подходит, если курсор находится в пределах 15 пикселей от кнопки по обеим осям.

const shouldUpdateApp = ({x, y}: MouseCoords): boolean => {
  const {top, left, widthRange, heightRange} = state.get()
  const padding = 15

  return inRange(x, left - padding, widthRange + padding) 
      && inRange(y, top - padding, heightRange + padding)
}

// ...

filter(shouldUpdateApp)

И тогда код observable будет выглядеть так:

const source = fromEvent(document, 'mousemove')

const observable = source.pipe(
  map((event: MouseEvent): MouseCoords => 
    ({ x: event.x, y: event.y })),
  filter(shouldUpdateApp))

Подписка на события

Каждый элемент в потоке стремится попасть в subscribe, где он будет как‑то обработан.

Метод subscribe принимает три функции‑аргумента. Первая функция обрабатывает новые элементы, вторая — ошибку, если она возникнет, третья — окончание потока:

observable.subscribe(
  // onNext, вызывается при появлении новых элементов, el — новый элемент
  (el) => {},

  // onError, вызывается, если произошла ошибка, er — объект ошибки
  (er) => {},

  // onCompleted, вызывается, когда поток завершён
  () => {},
)

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

observable.subscribe(() => updateApp())

const updateApp = () => {
  const {left, top} = getNewPosition()
  state.update({ left, top })

  applyStyle(button, {
    left: `${left}px`,
    top: `${top}px`,
  })
}

Результаты

Я не буду подробно останавливаться на классе, который управляет состоянием приложения, и функциях‑хелперах. Исходный код всего‑всего можно посмотреть на Гитхабе.

Сама игрушка получилась очень простой, хотя для знакомства с RxJS вполне ок.

Конечно, там ещё куча всякого, о чём я не рассказал: создание потоков из промисов, Subject, Scheduler, куча операторов, работу которых иногда без специального сервиса не разберёшь. Но для начала — сойдёт.

Ссылки

Сделяль

• сама игрушка
• исходники

Шаблон «Наблюдатель» и ФРП

• в Википедии
• на Гитхабе
• The introduction to Reactive Programming you’ve been missing
• RxJS in 5 minutes!

Документация RxJS

• Observable
• fromEvent

Операторы

• введение
• map
• filter

Книги и сервисы

• Angular и TypeScript. Сайтостроение для профессионалов
• RxMarbles