• Главная
  • Контакты
Подписаться:
  • Twitter
  • Facebook
  • RSS
  • VK
  • PushAll
logo

logo

  • Все
    • Положительные
    • Отрицательные
  • За сегодня
    • Положительные
    • Отрицательные
  • За вчера
    • Положительные
    • Отрицательные
  • За 3 дня
    • Положительные
    • Отрицательные
  • За неделю
    • Положительные
    • Отрицательные
  • За месяц
    • Положительные
    • Отрицательные
  • За год
    • Положительные
    • Отрицательные
  • Сортировка
    • По дате (возр)
    • По дате (убыв)
    • По рейтингу (возр)
    • По рейтингу (убыв)
    • По комментам (возр)
    • По комментам (убыв)
    • По просмотрам (возр)
    • По просмотрам (убыв)
Главная
  • Все
    • Положительные
    • Отрицательные
  • За сегодня
    • Положительные
    • Отрицательные
  • За вчера
    • Положительные
    • Отрицательные
  • За 3 дня
    • Положительные
    • Отрицательные
  • За неделю
    • Положительные
    • Отрицательные
  • За месяц
    • Положительные
    • Отрицательные
  • Главная
  • Архитектура модульных React + Redux приложений 2. Ядро

Архитектура модульных React + Redux приложений 2. Ядро +12

24.04.2017 07:04
marshinov 3 4400 Источник
Разработка веб-сайтов*, Проектирование и рефакторинг*, Анализ и проектирование систем*, JavaScript*
В первой части я уделил внимание только общей концепции: редюсеры, компоненты и экшны чаще меняются одновременно, а не по отдельности, поэтому и группировать и их целесообразнее по модулям, а не по отдельным папкам actions, components, reducers. Также к модулям были предъявлены требования:

  1. быть независимыми друг от друга
  2. взаимодействовать с приложением через API ядра

В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем.
Начнем с определения модуля. Работать с простым объектом не совсем удобно. Добавим немного ООП:

const _base = Symbol('base')
const _ref = Symbol('ref')

class ModuleBase{
  constructor(base){
    this[_base] = base
    this[_ref] = getRef(this)
  }

  /**
   * unique module id
   * @returns {string}
   */
  get id(){
    return this.constructor.name
  }

  /**
   * full module ref including all parents
   * @returns {string}
   */
  get ref(){
    return this[_ref]
  }

  /**
   * module title in navigation
   * @returns {string}
   */
  get title(){
    return this.id
  }

  /**
   * module group in navigation
   * @returns {string}
   */
  get group(){
    return null
  }

  /**
   * react component
   * @returns {function}
   */
  get component() {
    return null
  }

  /**
   * router route
   * @return {object}
   */
  get route(){
    return getRoute(this)
  }

  /**
   * router path
   * @return {string}
   */
  get path(){
    return this.id
  }

  /**
   * children modules
   * @return {Array}
   */
  get children(){
    return []
  }

  /**
   * @type {function}
   */
  reduce
  //....
}
В коде выше для реализации инкапсуляции используются символы.
Теперь объявление модуля более привычно – необходимо унаследовать класс ModuleBase, переопределить необходимые геттеры и по желанию добавить функцию reduce, которая будет выполняться функцию редюсера.

В прошлый раз мы ограничили вложенность модулей вторым уровнем. В реальных приложениях этого бывает недостаточно. Кроме этого в прошлый раз нам нужно было выбирать между редюсером родительского модуля и комбинацией редюсеров дочерних. Это «ломает» композицию.

Например, если мы хотим создать стандартный CRUD над сущностью в БД логично организовать модули так:

/SomeEntity
  /components
    /Master.js
  /children
    /index.js
    /create.js
    /update.js
  /index.js

Считаем, что для create и update используются стандартный компонент формы, а для вывода данных стандартный компонент Grid из ядра системы, поэтому достаточно определить только модули для этих операций.

Родительский модуль отвечает за вывод лейаута, ссылок «создать», «назад к списку» и сообщений об успешности или не успешности запросов к серверу. Index – за фильтрацию, пагинацию и ссылки. Create и Update выводят формы на создание и редактирование.

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

Для роутов


const getRoute = module => {
  const route = {
    path: module.path,
    title: module.title,
    component: module.component
  }

  const children = module.children
  if(children) {
    ModuleBase.check(children)
    const index = children.filter(x => x.id.endsWith(INDEX))
    if(index.length > 0){
      // share title with parent module
      route.indexRoute = {
        component: index[0].component
      }
    }

    route.childRoutes = module.children
      .filter(x => !x.id.endsWith(INDEX))
      .map(getRoute)
  }

  return route
}

И для реюсеров


class ModuleBase{
  //....
  combineReducers(){
    const childrenMap = {}

    let children = Array.isArray(this.children) ? this.children : []
    ModuleBase.check(children)

    const withReducers = children.filter(x => typeof(x.reduce) === 'function' || x.children.length > 0)
    for (let i = 0; i < withReducers.length; i++) {
      childrenMap[children[i].id] = children[i]
    }

    if(withReducers.length == 0){
      return reducerOrDefault(this.reduce)
    }

    const reducers = {}
    for(let i in childrenMap){
      reducers[i] = childrenMap[i].combineReducers()
    }

    const parent = this
    const reducer = typeof(this.reduce) === 'function'
      ? (state, action) => {
        if(!state){
          state = parent.initialState
        }

        const nextState = parent.reduce(state, action)

        if(typeof(nextState) !== 'object'){
          throw Error(parent.id + '.reduce returned wrong value. Reducers must return plain objects')
        }

        for(let i in childrenMap){
          if(!nextState[i]){
            nextState[i] = childrenMap[i].initialState
          }

          nextState[i] = {...reducers[i](nextState[i], action)}
          if(typeof(nextState[i]) !== 'object'){
            throw Error(childrenMap[i].id + '.reduce returned wrong value. Reducers must return plain objects')
          }
        }

        return {...nextState}
      }
      : combineReducers(reducers)


    return reducer
  }

Это не самая эффективная реализация подобного редюсера. К сожалению, даже она заняла у меня достаточно много времени. Буду благодарен, если кто-то в комментариях подскажет, как можно сделать лучше.

Соответствие роутов и стейта


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

  1. /Update заменяется на /:id
  2. /Index опускается (используется indexRoute)
  3. Для Delete нет своего роута. Удаление производится из модуля Index

Метод path можно переопределить и тогда роут будет отличать от названия модуля. Можно конструировать цепочки модулей любой вложенности. Более того, если в вашем приложении только один корневой роут /, то целесообразно сделать модуль App и вложить в него все остальные, чтобы использовать один подход повсеместно.
Это позволит в редюсере App (если такой нужен) обрабатывать любые события приложения и модифицировать состояние любого дочернего модуля. Пожалуй, это слишком круто для любого, даже самого крутого редюсера. Я не рекомендую вообще переопределять reduce для родительского модуля приложения. Однако, такой редюсер может быть полезен для каких-то системных операций.

С роутингом покончено, осталось «законектить» компоненты к стейту. Так как редюсеры скомпонованы рекурсивно в соответствие со вложенностью дочерних модулей коннектить будем также. Здесь все просто. Реализацию mapDispatchToProps рассмотрим чуть ниже.

Компоненты ядра


Итак, ModuleBase– первая и неотъемлемая часть ядра. Без него свой код к приложению вообще не подцепить. ModuleBase предоставляет следующее API:

  1. Регистрация компонента в роутере
  2. Регистрация редюсера модуля
  3. Connect компонентов к стейту redux

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

Компоненты и контейнеры


Контейнеры – один из широко распространённых паттернов в React. Если коротко, то разница между компонентами и контейнерами в следующем:

  1. Компоненты (или презентационные компоненты) не содержат внешних зависимостей и логики
  2. Контейнеры (как понятно из названия) оборачивают компоненты, реализуя байндинг между внешним миром и компонентами

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

Для разработки DataGridModule нам потребуются:

  1. компонент DataGrid
  2. его контейнер DataGridContainer
  3. редюсер для связи между контейнером и состоянием приложения в redux

Реализацию презентационного компонента я опускаю. Для подключения к стейту у нас есть функция ModuleBase.connect. Осталось получать данные с сервера. Можно на каждый грид создавать новый класс и переопределять componentDidMount или другие методы жизненного цикла компонента. Подход, в целом, рабочий, но имеющий два значительных недостатка:

  1. гигантское количество boilerplate и копипасты. А копи-пейст, как известно, всегда приводит к ошибкам
  2. низкая скорость разработки модулей (ядро пока не предоставляет никакого API для ускорения разработки, это неправильно)

Примеси (mixin)


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

Расширим возможности компоновки компонентов и контейнеров с помощью mixin’ов. class и extends – это объекты первого класса в ES6. Иными словами, запись const Enhanced = superclass => class extends superclass корректна. Это возможно, благодаря системе наследования JavaScript, основанной на прототипах.

Добавим в ядро функцию mix и примеси Preloader и ServerData:

const Preloader = Component => class extends Component {
  render() {
    const propsToCheck = subset(this.props, this.constructor.initialState)
    let isInitialized = true
    let isFetching = false

    for(let i in propsToCheck){
        if(typeof(propsToCheck[i][IS_FETCHING]) === 'boolean'){
          if(!isFetching && propsToCheck[i][IS_FETCHING]){
            isFetching = true
          }

          // if something except "isFetching" presents it's initialized
          if(isInitialized && Object.keys(propsToCheck[i]).length === 1){
            isInitialized = false
          }
        }
    }

    return isInitialized
      ? (<Dimmer.Dimmable dimmed={isFetching}>
        <Dimmer active={isFetching} inverted>
          <Loader />
        </Dimmer>
        {super.render()}
      </Dimmer.Dimmable>)
      : (<Dimmer.Dimmable dimmed={true}>
        <Dimmer active={true} inverted>
          <Loader />
        </Dimmer>
        <div style={divStyle}></div>
      </Dimmer.Dimmable>)
  }
}

const ServerData = superclass => class extends mix(superclass).with(Preloader) {
  componentDidMount() {
    this.props.queryFor(
      this.props.params,
      subset(this.props, this.constructor.initialState))
  }

Первый проверяет все ключи в стейте и если находит хотя-бы один с определенным свойством isFetching: true выводит поверх компонента диммер. Если кроме isFetching в объекте свойств нет, считаем, что они должны прийти с сервера и вообще не отображаем компонент (считаем не инициализированным).

Миксин ServerData автоматически подмешивает прелоадер и переопределяет componentDidMount.

queryFor


Рассмотрим более подробно реализацию queryFor. Ее передал Module.connect через mapDispatchToProps.

export const queryFactory = dispatch => {
  if(typeof (dispatch) != 'function'){
    throw new Error('dispatch is not a function')
  }

  return (moduleId, url, params = undefined) => {
    dispatch({
      type: combinePath(moduleId, GET),
      params
    })

    return new Promise(resolve => {
      dispatch(function () {
        get(url, params).then(response => {
          const error = 'ok' in response && !response.ok
          const data = error
            ? {ok: response.ok, status: response.status}
            : response

          dispatch({
            type: combinePath(moduleId, GET + (error ? FAILED : SUCCEEDED)),
            ...data
          })

          resolve(data)
        })
      })
    })
  }
}

export const queryAll = (dispatch, moduleRef, params, ...keys) => {
  const query = queryFactory(dispatch)
  if(!keys.length){
    throw new Error('keys array must be not empty')
  }

  const action = combinePath(moduleRef, keys[0])
  let promise = query(action, fixPath(action), params)
  for(let i = 1; i < keys.length; i++){
    promise.then(() => {
      let act = combinePath(moduleRef, keys[i])
      query(act, fixPath(act), params)
    })
  }
}

export const queryFor = (dispatch, moduleRef, params, state) => {
  const keys = []

  for (let i in state) {
    if (state[i].isFetching !== undefined) {
      keys.push(toUpperCamelCase(i))
    }
  }

  return queryAll(dispatch, moduleRef, params, ...keys)

С помощью queryFactory создаем функцию query, которая делает запрос на сервер, диспатчит в store соответствующие события и возвращает promise, чтобы можно было выстроить цепочку запросов функции в queryAll, список запросов в которую передаст та самая функция queryFor, которая ориентируется на наличие isFetching в объекте в доме, который построил Джек.

Допишем «обогощалку» для стейта, требующего серверных данных:

ServerData.fromServer = (initialState, ...keys) => {
  for(let i = 0; i < keys.length; i++){
    initialState[keys[i]].isFetching = false
  }

  return initialState
}

Теперь достаточно знать правила использования миксина, чтобы сделать из любого компонента, работающего с клиентскими данными на серверный. Достаточно правильно настроить initialState и подключить mixin.

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

ServerData.reducerFor


ServerData.reducerFor = (moduleRef, initialState, next = null, method = GET) => {
  if(!moduleRef){
    throw Error('You must provide valid module name')
  }

  if(!initialState){
    throw Error('You must provide valid initialState')
  }

  const reducer = {}

  for (let i in initialState) {
    reducer[i] = hasFetching(initialState, i)
      ? ServerData.serverRequestReducerFactory(combinePath(moduleRef, i), initialState[i], next, method)
      : passThrough(initialState[i])
  }

  if(Object.keys(reducer) < 1){
    throw Error('No "isFetching" found. Cannot build reducer')
  }

  const combined = combineReducers(reducer)
  return combined
}

export default class DataGridModuleBase extends ModuleBase {
  constructor(base){
    super(base)
    // Create is required due to children module
    this.reduce = ServerData.reducerFor(this.ref, DataGridContainer.initialState)
  }

  get component () {
    return this.connect(DataGridContainer)
  }
}

Добавляем модуль с гридом в приложение


export default class SomeEntityGrid extends DataGridModuleBase {
}
//..
const _children= Symbol('children')
export default class App extends ModuleBase{
  constructor(base){
    super(base)
    this[_children] = [new SomeEntityGrid(this)]
  }

  get path (){
    return '/'
  }

  get component () {
    return AppComponent
  }

  get children(){
    return this[_children]
  }

Если вы дочитали до конца, то FromModuleBase сможете реализовать по аналогии.

Финальная структура ядра


/core
  /ModuleBase.js
  /api.js
  /components
  /containers
  /modules
  /mixins

  1. Базовые модули содержат повторно-используемую логику и наборы стандартных компонентов, часто используемых вместе (например, CRUD).
  2. Папки components и containers содержат часто-используемые компоненты и контейнеры, соответственно.
  3. С помощью примесей можно компоновать компоненты и контейнеры: грид с серверными данными, грид с инлайн-вводом, грид с серверными данными и инлайн-вводом и т.д.
  4. api.js содержит функции для работы с сервером: fetch, get, post, put, del,…

Разделение ответственности


  1. Модули: роутинг, создание контейнера, передача необходимых функций в контейнер, редюсер для компонента, предоставление мета-информации.
  2. Компоненты: повторно-используемые части UI. Хорошо сочетаются с БЭМ. Могут разрабатываться независимо от основного приложения отдельной командой.
  3. Контейнеры: отображение состояния приложения и набора API на презентационные компоненты.
  4. Дополнительные middleware: не используются. Вместо них только redux-thunk. Дополнительные middleware не используются потому что это усложняет систему. Использование redux-saga сильно задирает кривую обучения и повышает размер бандла, поэтому предпочтение отдается thunk
Поделиться с друзьями
-->

Комментарии (3)


  1. justboris
    24.04.2017 11:45
    #10188274
    +1

    Вы используете символы для приватных свойств, например [_children], но непонятно, откуда они берутся. В последнем примере кода:


    export default class App extends ModuleBase{
      constructor(base){
        super(base)
        this[_children] = [new SomeEntityGrid(this)]
      }
    }

    Откуда здесь берутся _children?


    1. marshinov
      24.04.2017 12:09
      #10188312
      -1

      Выше объявлены
      const _children= Symbol('children')

      Дописал в статью


  1. comerc
    24.04.2017 14:12
    #10188558
    +7

    Простите меня, ассоциация: "и со всем этим мы попробуем взлететь".

МЕТКИ

  • Хабы
  • Теги

Разработка веб-сайтов

Проектирование и рефакторинг

Анализ и проектирование систем

JavaScript

react

redux

модульное программирование

СЕРВИСЫ
  • logo

    CloudLogs.ru - Облачное логирование

    • Храните логи вашего сервиса или приложения в облаке. Удобно просматривайте и анализируйте их.
Все публикации автора
  • Архитектура модульных React + Redux приложений 2. Ядро +12

    • 24.04.2017 07:04

    Архитектура модульных React + Redux приложений +14

    • 14.04.2017 00:27

    Введение в React и Redux для бекенд-разработчиков +21

    • 10.04.2017 22:40

    Функциональный C# +25

    • 30.03.2017 18:25

    Шаблон проектирования «Спецификация» в C# +6

    • 30.03.2017 11:51

    Union Type, TPT, DDD, ORM и RDBMS +7

    • 20.02.2017 06:05

    DotNext — Moscow 2016. Как это было +33

    • 14.12.2016 15:55

    Устранение дублирования Where Expressions в приложении +14

    • 23.10.2016 16:52

    Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали +39

    • 19.10.2016 12:22

    Pipelining в C#-приложениях +13

    • 18.08.2016 13:12

Подписка


ЛУЧШЕЕ

  • Сегодня
  • Вчера
  • Позавчера
06:00

Запустили векторный поиск в YDB: рассказываем, как он работает +65

10:31

А вдруг прочитают? Как писать для инопланетян +20

09:01

10 популярных мифов о VDS-хостинге +20

08:22

Топ-5 мини-ПК с фокусом на производительность: от Arrow Lake до Strix Halo +20

07:49

Почему 21 см — это «магическая длина» нашей Вселенной +20

13:01

Ну, погоди! Как я создал свою версию культовой игры: от схемы до корпуса +17

08:05

Шифрование скриптов +17

11:56

Меню потоков уже на Хабре +16

08:33

Атомные реакторы для лечения рака (и почему они больше не нужны) +16

09:33

Призраки в коммитах: пылесосим историю Git в поиске утекших секретов +15

07:44

Мы сделали химическую защиту собачьих лап +14

12:39

Как сыграть с СХД в имитацию ошибки и выйти победителем? Используем паттерны ООП на C++ +10

06:45

Steroids — ещё один фронтенд фреймворк на базе React? +10

12:44

Выгорание одно. Причины разные +9

11:00

Масштабирование AI/ML-инфраструктуры в Uber +9

07:41

Вы точно их собеседовали: 8 личностей, которые приходят на интервью +9

07:37

Python в enterprise-разработке: почему популярность ЯП распространилась и на корпоративный сектор. Часть 2 +9

02:02

Кубик мысли: простой проект, который говорит вместо тебя +9

13:06

Как я за год в магистратуре погрузился в мир искусственного интеллекта +8

06:25

Как машинное обучение приручает хаос биологических данных +7

09:01

Большинству людей плевать на качество софта +99

14:07

Вы тоже заказываете платы, компоненты и всячину здесь? +79

13:01

Пишем простой драйвер Linux для устройства, ничего не зная о драйверах и о USB +62

08:27

Телеграфируем кодом Морзе через Java Stream API (часть 1 из 2) +46

07:29

Простой ультразвуковой отпугиватель собак +36

19:20

Почему я отказался внедрять тёмные паттерны и не получил оффер на фронтенд-лида +34

11:34

Лучшее IT-событие этого лета. За что говорят «спасибо» Summer Merge +27

12:49

Сжатие текста в Angie: статика, динамика, производительность +21

07:00

Одноплатники как роутеры: новинки 2025 года и их возможности +20

22:23

Верните непрерывную интеграцию разработчикам +19

08:50

Б/У Antminer S9 в помощь радиолюбителю +18

09:00

200 тысяч единиц уже готовы, еще миллион — на подходе: разворачиваем контуры в один клик +16

04:50

Илон Маск создал Меха-Гитлера, а также релиз самого умного Grok 4 +16

09:10

Как я полюбил LESS и с его помощью избавился от копипасты в своём CSS-коде, а разметку сделал семантической +15

05:54

MCP для новичков +15

15:18

Как мы в Авито используем split-тесты для оценки алгоритмов продвижения объявлений +14

12:32

Как я случайно стал UI-дизайнером радиоприёмника — и заработал 60к за 15 часов +11

07:07

Недельный геймдев: #234 — 13 июля, 2025 +11

16:34

Как я пишу код быстрее +10

07:46

Внедрение зависимостей (DI) через библиотеку Tsyringe +10

16:16

Как «по-быстрому» сделанная игра затянула меня в геймдев на 20 лет и какие выводы я из этого сделал +96

09:01

От React всё также веет безумием, но все об этом молчат +96

13:39

Как выйти из IT?.. и пойти слесарем на завод. Моя попыточка дауншифтинга [1\4] +67

13:01

Большое испытание кальциевых аккумуляторов, часть 2: недозаряд портит, а кипячение убивает +42

08:02

Commodore 64 Ultimate: возрождение легенды в 2025 году +40

13:05

Кладбище криминальных экшенов. Почему почти все клоны GTA провалились, а студии закрылись +19

08:00

Без(д)воз(д)мездно, то есть даром +17

08:13

Новый рекорд по упаковке сфер неожиданно пришёл из геометрии +15

12:00

Как я пришёл в open source в 2025-м (с утилитой для бекапа PostgreSQL), чуть не потеряв проект на ~$1500\мес в 2023-м +14

07:16

Конфаундинг, или как аналитику попасть в ловушку +14

05:16

Алгоритмы для работы с большими данными в Go: HyperLogLog и Count-Min Sketch +12

17:50

Как собрать друзей на игру и не сойти с ума: мой бот для геймеров +10

08:00

Кремниевая революция по-китайски: как Пекин собирается обойти Тайвань и США к 2030 году +10

08:16

«Хочу, но боюсь и не делаю»: что делать со страхом того, что не получится? +9

06:15

Vue: Composables и TS это вам не Mixins и JS. С ними сложнее +8

15:35

Как ваш полет домой поможет инопланетянам определить местоположение Земли +7

10:15

Как дизайн Kaspersky Thin Client пережил подростковый бунт (и что из этого вышло) +7

10:15

Как дизайн Kaspersky Thin Client пережил подростковый бунт (и что из этого вышло) +7

10:08

Свой ChatGPT на документах: делаем RAG с нуля +7

09:02

Kubernetes на базе Deckhouse в облаке Linx Cloud: встроенный мониторинг, безопасность и управление сертификатами +7

ОБСУЖДАЕМОЕ

  • От React всё также веет безумием, но все об этом молчат +96

    • 279   34000

    Большинству людей плевать на качество софта +99

    • 222   23000

    Что делать вайбкодеру после 07/07 -3

    • 98   48000

    No Cars Allowed? Что с трендом на улицы без авто +5

    • 78   2600

    Простой ультразвуковой отпугиватель собак +36

    • 72   6300

    Вы тоже заказываете платы, компоненты и всячину здесь? +79

    • 63   22000

    Без(д)воз(д)мездно, то есть даром +17

    • 61   15000

    Скоро без нас: когда роботы окончательно отберут нашу работу? +5

    • 49   3100

    Как «по-быстрому» сделанная игра затянула меня в геймдев на 20 лет и какие выводы я из этого сделал +96

    • 45   23000

    Шифрование на основе хешей -6

    • 39   4400

    Почему я отказался внедрять тёмные паттерны и не получил оффер на фронтенд-лида +37

    • 36   8900

    Как я пришёл в open source в 2025-м (с утилитой для бекапа PostgreSQL), чуть не потеряв проект на ~$1500\мес в 2023-м +14

    • 36   15000

    Из личного VPN в целый сервис -2

    • 31   8400

    Как выйти из IT?.. и пойти слесарем на завод. Моя попыточка дауншифтинга [1\4] +67

    • 31   13000

    Одноплатники как роутеры: новинки 2025 года и их возможности +20

    • 29   12000
  • Главная
  • Контакты
© 2025. Все публикации принадлежат авторам.