Props или State, если будет только одно обновление?
В приложении древовидная структура компонентов, конечные, самые глубокие, назову «листиками». Листики имеют id, которые сохраняются в приложении. А также с внешнего сервиса по этим id получают доп. данные: напр. аватарку и ссылку.
Изначально приложение получает данные, по которым строится это дерево, и только id для конечных узлов, этих листиков. И тут надо запросить доп. данные с внешнего сервиса, чтобы правильно отрисовать эти листики. Т.о. у него бывает два состояния: свежесозданный, с только-id, и получивший все данные с внешнего сервиса чуть позже. Пользователь доп. данные никак не меняет, они нужны только для отображения.
Когда пользователь добавляет новые ветви, а затем «вешает» на них новые листики, всё то же: сначала только id, затем запрос и доп. данные в перерисовку листика.
Вопрос: следуя философии ReactJS, следует ли передавать id по цепочке props, а запрос доп. данных инициировать в каждом из листиков индивилуально, а полученные доп. данные хранить в state; или всё передавать из корня всего приложения через props по всему каскаду вложенных компонентов; или как-то ещё?
Хорошим решением будет сделать некоторые компоненты вверху дерева как Controller-View, которые будут иметь state и получать данные, а в остальном старайтесь делать компоненты stateless (док).
React.js настолько гибок, что развязывает нам руки: каждый способен придумать своё оригинальное решение. С приходом Flux и его хранилищ, я стал использовать принцип передавать через props минимальный набор данных; всё что компонент может взять сам, пусть сам и берёт. Таким образом, компонент у меня чаще всего получает только id, а при рендере недостающие данные он самостоятельно получит из внешних источников.
В Вашем случае, если внешних источников нет, сохраняйте данные прямо в state компонента.
Отличный способ убить универсальность. Согласно докам реакта: "Most of your components should simply take some data from props and render it... Try to keep as many of your components as possible stateless"
Никита Гущин: Представьте очень сложный проект, где один из компонентов (назовём его "К") "закопан" так глубоко, что для того, чтобы передать ему какие-то параметры через props, придётся их пробрасывать с самого верха, от "А" до "К". Поверьте, не такое уж это и приятное занятие. А если нужно будет обновить этот компонент, как Вы будете менять его props-ы? Ни как. Текущая реализация React-а запрещает делать setProps() у компонента, который имеет родителя, поэтому Вам придётся менять props в компоненте "A", что приведёт к лишней перерисовке всех незатронутых компонентов (не думаю, что кто-то сильно заморачивается с shouldComponentUpdate()).
Посмотрите на примеры Flux-а: там компонент отвечает сам за себя, и при рендере он самостоятельно забирает из хранилищ все нужные ему данные, подписываясь при этом на их события. И при изменении данных (и правильной архитектуре) перерисовываться будет не компонент "А", а только те компоненты, который были затронуты этими изменениями, например тот же "К".
Finnish: Это сложный проект. "К" закопан очень глубоко, ему нужны данные. Значит эти данные связаны. Или в этом проекте в одной ветке дерева 95% компонентов рисуют информацию об автомобилях, а компонент "К", находящийся очень глубоко, рисует курс валют, например? Тогда это проблемы архитектуры. А если данные связаны, то их пробрасывать - это нормальное занятие. Отсюда вывод - если данные изменились перерисоввываются только компоненты, которые непосредственно работают с этими данными. Такой основной принцип реакта - компоненты это конечный автомат. В вашей реализации этот принцип нарушается - так как непонятно откуда компонент получает данные и с одинаковыми props один и тот же компонент может отрисоввываться по-разному.
Finnish: Про componentUpdate - опять же, если данные не связаны и у вас рисуется что попало где попало - то да, вы получаете выигрыш. Если же архитектура нормальная, компоненты "pure render", при этом обычно все данные immutable, то их перерисовка в реакте - это очень быстрое занятие и так и задумано. Потому что в итоге перерисуются только те компоненты, в которых изменились props. А так как props - immutabe -> в componentShouldUpdate у нас просто проверка по ссылке a === b, которая ну просто супер быстрая и ресурсов не ест.
Finnish: Далее про реализации Flux - я попробовал несколько и сейчас остановился на Redux. Там все данные хранятся в одном дереве. Отличная архитектура - легко тестировать, one way data flow и так далее. Можете глянуть видео прое редукс, там Дэн Абрамов рассказывает что и почему не катит в классическом flux с событиями и подпиской на них где-попало.
Средний