2015-03-12 6 views
2

У меня есть приложение в React, которое на базовом уровне представляет собой документ, который отображает данные с произвольного количества «дочерних» ресурсов второго уровня, и каждый дочерний элемент отображает данные с произвольного количества ресурсов внука 3-го уровня, и каждый внук отображает данные с произвольного количества ресурсов «правнуков» 4-го уровня.Манипулирование глубоко вложенным объектом данных (в реактиве)

Это базовая структура JSON извлекается из моего API сервера:

{ id: 1, 
    children: [ 
    { id: 1, 
     grandchildren: [ 
     { id: 1, 
      greatgrandchildren: [{ id: 1 }, { id: 2 }, ...] 
     }, 
     ... 
     ] 
    }, 
    ... 
    ] 
} 

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

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

Это прекрасно, однако мне нужно иметь возможность выполнять операции CRUD (создание/чтение/обновление/удаление) на каждом ресурсе, и это оказывается больно из-за необходимости передать весь объект данных до setState(), когда я просто пытаюсь изменить небольшую его часть. Это не так плохо на верхнем или втором уровнях, но что-то прошлое, и что-то быстро становится неудобным из-за необходимости итерации, выберите объект, который я хочу, на основе id, измените его, а затем создайте копию всей структуры только с этим бит изменен. Добавления React предоставляют функцию update(), что полезно, но на самом деле помогает только с последнего шага - мне все же приходится иметь дело с вложенной итерацией и перестраивать соответствующий массив вне этого.

Добавлена ​​дополнительная сложность, поскольку моя цель - оптимизировать обновление данных временными данными, а затем обновить его снова с помощью правильных данных, которые возвращаются с сервера (при успешном завершении) или возвращаются (при сбое). Это означает, что мне нужно быть осторожным, чтобы сохранить копию старых данных/состояний без их изменения (например, обмен ссылками).

Наконец, у меня есть метод обратного вызова для каждого действия CRUD для каждого уровня, определенного на моем компоненте верхнего уровня (всего 12 методов). Это кажется чрезмерным, но все они нуждаются в возможности позвонить this.setState(), и мне сложно разобраться, как реорганизовать общность среди них. У меня уже есть отдельный объект API, который выполняет фактические вызовы Ajax.

Итак, мой вопрос: существует ли более подходящий подход для работы с CRUD-операциями и манипулирование данными для них с вложенной структурой данных, как у меня, таким образом, чтобы обеспечить оптимистичные обновления?

ответ

2

После небольшого исследования я понял, что проблема изменения состояния является одной из причин того, что библиотеки неизменяемости (например, immutable.js и mori) кажутся горячей темой в сообществе React, поскольку они облегчают модификацию небольшие части глубоко вложенных структур, сохраняя при этом оригинальную копию нетронутой. После некоторого рефакторинга мне удалось лучше использовать вспомогательный помощник React.addons.update() и немного уменьшить его, но я думаю, что использование одной из этих библиотек было бы следующим логическим шагом.

Что касается структуры/организации, кажется, для решения этой проблемы существует Flux (или другая архитектура, подобная MV *), что имеет смысл, потому что React - это просто библиотека представлений.

2

Поверхность выглядит так: flux architecture может быть ответом, который вы ищете. В этом случае у вас будет Store для каждого типа ресурсов (или, может быть, один Store для всего этого, в зависимости от структуры данных) и просматривать мнения о изменениях в данных, которые им нужны.

Смежные вопросы