От земли к FPV Квадрокоптеру: Введение

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

От земли к FPV Квадрокоптеру: Введение

Загорелся прошлой зимой. Сразу взял RTF комплект, но 2 месяца ждал, пока снег сойдет. К концу года итог — один дрон в кашу, два собранных, один потерял на ровном месте, закуплена комплектуха ещё на 2, не считая мелкаша, на которых гоняем в помещении зимой. Последний видос: https://youtu.be/MPlhAXf_YEU

Опыт использования redux без редьюсеров

Подход в следующем:

1. Обрабочтики компонет (экшены) непосредственно мутируют глобальный стейт. Диспатчем просто новая версия кладется в store
2. Для удобства работы с глобальным глубоко вложенным стейтом, используется библиотека.

Я не пропускаю весь ввод с клавиатуры в формах через redux. Т.к. по сути изменение сосотояния приложения произойдет после отправки данных на сервер. (Использую state)

Это у вас форма ввода слишком простая. От значения вашего контрола ничего не зависит. Даже в статье, это не так.
За ссылки спасибо

Опыт использования redux без редьюсеров

Получаем 2000, 3000, 4000… И т.д…

Я однажды видел реализованную в экселе картографию. Реально, карта России, нарисованная пиксельно в ячейках. Внутри карты так же пиксельно раскрашивались регионы в соответствии с показателями. Среди всей гаммы чувств, при виде этого, особенно сильными были «Офигеть!» и «Нафига?». Вы, видимо, собираетесь не меньше чем сапера замутить)))

Если серьезно, то вот я взял первый попавшийся реальный файл с постановкой. На фулскрине — 12*16 ячеек. Я уверен, что даже 400 привязанных ячеек(по одному значению) не вызовут заметных лагов на блур. Другой вопрос, что это, как Вы заметили, «архитектурно не оптимально». Однако, пока это дешево в реализации, решает задачу и не лагает, это может быть приемлемо.

Connect со своей логикой — это круто. Надо будет поковыряться на досуге в этом направлении. Может быть есть где почитать кроме исходников react-redux?

Еще вариант оптимизации на стандартном connect — это сделать составной ключ строка*столбец, аналогично хранить данные data[row][col]. Привязать только таблицу, сделать отдельным компонентом строки. Строки и ячейки как PureComponent. При рендере, компонентам раздавать свои данные. Количество shallow-comparison проверок будет много меньше.

Опыт использования redux без редьюсеров

Помимо желания поделиться своим опытом (о чем многим, уверен, было бы интересно почитать подробнее), в вашем комменте читается желание покритиковать. Но вот только я пока не понял что именно))
Создатели Redux не принуждают зацикливаться на дефолтном combineReducers, чем пользуетесь и Вы и я.

Позвольте только вопрос. Насколько понимаю, action-type у вас является константа вида «A.B.C» (либо массив/объект). Вы его импортируете из того же файла где лежит и хэндлер. А потом, диспатчем бросаете тип в «черный ящик», который, по факту, тут же вызывает ваш хендлер по принципу reducer['A']['B']['C'](state, action). В чем сакральный смысл такого непрямого вызова? Активно пользуетесь мидлварами? Или просто удобно часть «модульной» логики класть в редьюсеры вне хэндлеров?

Про эксель — решал бы в лоб.
Рендерятся те ячейки, что помещаются в видимую область. Каждая ячейка имеет адрес и данные в стейте в Map-е data[address]. С помощью immutable-selectors удобно получать данные из коллеккций. Объект — дерево выглядел бы таким образом:

const selectors  = {
  data:{
    param:'x'
  }
};

Ячейки привязаны стандартным connect через mstp вида

return{
  value:selectors.data(state, ownProps.address)
}

По изменению ячейки, либо блуру, вызов action-creator-а

export function onChange(address, newValue) {
  return function (dispatch, getState) {
    dispatch({
      type:'Изменение ячейки',
      setState: selectors.data.replace(getState(), newValue, address),
      payload: { address, newValue }
    });
  };
}

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