• Главная
  • Контакты
Подписаться:
  • 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

Подписка


ЛУЧШЕЕ

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

Localhost-атака: как Meta и Яндекс отслеживали пользователей Android через localhost +68

21:57

Как инфоцыгане отравили IT +40

13:01

Апгрейды для Денди: часть 2/2 +40

08:14

Paranoia Mode: подборка инструментов для приватной и безопасной работы в Linux +37

09:01

Электронная нагрузка для разряда аккумуляторов на микроконтроллере PIC16F628A +32

08:23

3D-сканер из датчика Kinect Xbox 360 +31

13:39

Прогрессивный JSON +28

12:55

Секреты изнанки музыкальных инструментов +24

12:02

Взломают или нет? Оцениваем риски вашей информационной системы и моделируем угрозы +19

10:38

Достижения российских ученых в первой половине 2025 года +19

11:31

Один на один с Rust +18

11:35

Об (отсутствии) синтаксической поддержки обработки ошибок в Go +17

08:05

Переводим спортивное табло на управление по Bluetooth и контроллер arduino +17

12:48

Философствующий Claude 4, Gemini для самых маленьких и пачка агентов-программистов: главные события мая в ИИ +16

09:45

Рецензия на книгу “Машинное обучение для приложений высокого риска” +15

02:09

LLM работают лучше если им угрожать? Вообще не факт +15

07:19

5 игровых проектов, которые разрушают ожидания за 15 минут. И это прекрасно +12

06:25

Разбираемся с новым Ryzen Threadripper Pro 9000 WX — до 5,4 ГГц и 96 ядер на процессор +12

15:00

Маленькая утилита для контроля квот в Yandex Cloud +9

13:21

Читаем под одеялом с фонариком: темная тема и документация в ТМС TestY 2.1 +9

06:47

5 смертельных проблем первого метро, и как их решили +64

07:00

Как мы встроили 32-битный Internet Explorer в 64-битный Яндекс Браузер для организаций +62

08:52

Stack Overflow убил не искусственный интеллект +61

13:01

Недистрибутивность деления, или Как я считал среднюю величину +56

16:18

Миссия невыполнима 2: как мы снова «похитили» радиатор +51

15:23

Как мы разрабатываем отечественный AI-процессор. Часть 1. Почему GPGPU? +48

12:00

Не украл, а вдохновился! Как геймдизайнеры крадут ассеты, модели, текстуры и уровни из чужих игр +42

08:07

Как измерить сезонность в SEO: пошаговая инструкция +41

09:01

Как сделать ужасный для пользователя интерфейс. Коллекция HTML/CSS лайфхаков +39

14:20

React Native тормозит? Проверь эти 8 узких мест в производительности, прежде чем винить фреймворк [ЧЕК-ЛИСТ] +33

10:13

Как перестать беспокоиться и начать внедрять интеграционные тесты +31

10:13

Как перестать беспокоиться и начать внедрять интеграционные тесты +31

06:52

Симуляция жизни частиц в браузере на WebGPU +31

18:20

Потрясающие фотографии Млечного Пути от лучших астрофотографов +29

17:21

Топ 10 заповедей системного дизайна +29

17:17

Почему в английском ТАК много слов +29

08:36

Фичи, кейсы и любовь – как палаточный IT-лагерь на 2К+ человек меняет жизни +26

15:31

std::launder: зачем и когда нужен +25

16:29

Лавандовый раф или стакан самогона: есть ли место на заводе хипстеру с макбуком +23

09:02

ContractFirst- vs CodeFirst-подходы, строим техпроцесс с нуля +23

ОБСУЖДАЕМОЕ

  • Stack Overflow убил не искусственный интеллект +61

    • 109   29000

    Почему в английском ТАК много слов +29

    • 75   7700

    Анатомия Отчуждения — Капитализм как Фабрика Неврозов и Пути Побега +3

    • 73   1900

    Недистрибутивность деления, или Как я считал среднюю величину +56

    • 62   4400

    5 смертельных проблем первого метро, и как их решили +64

    • 59   10000

    Как выбрать очки, чтобы не ослепнуть +19

    • 47   2900

    Как мы встроили 32-битный Internet Explorer в 64-битный Яндекс Браузер для организаций +62

    • 41   7500

    Как мы разрабатываем отечественный AI-процессор. Часть 1. Почему GPGPU? +48

    • 38   5800

    Что мы теряем, доверяя ИИ? +4

    • 37   1400

    Конец эпохи программистов? Почему 80% IT-школ закроются к 2027 году -11

    • 36   2000

    Как инфоцыгане отравили IT +40

    • 33   4800

    Лавандовый раф или стакан самогона: есть ли место на заводе хипстеру с макбуком +23

    • 33   5500

    Проверенный стек технологий для быстрого создания Web SaaS в 2025 году +2

    • 33   916

    Localhost-атака: как Meta и Яндекс отслеживали пользователей Android через localhost +68

    • 31   6400

    Об (отсутствии) синтаксической поддержки обработки ошибок в Go +17

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