Комментарии 28
Интересно, а если данные, положенные в getChildContext не статичные, а подтягиваются из стора. И в случае, если данные изменились, то в дочерних элементах все автоматически обновится или нужно что-то на подобии componentWillReceiveProps?
Но самый элегантный путь — это использование контекста.
По рукам надо за такое бить. Не документированная фича — это не просто так, что разработчики забыли. Это очень спорная фича, не до конца реализованная и не факт, окажется ли она в 1.0, или будет точно такой же в следующих релизах.
Разработчики заявляли, что эта фича войдет в 1.0 и будет допилена и задокументирована. К сожалению, под рукой нет пруфа.
Context'ы — задокументированная фича, но не полностью, тот же React Router работает как раз на основании контекстов. Но дальше чем роутинг, я бы контекстами не пользовался, иначе получим проблему скоупов от Ангуляра. Проще уж Стор сделать для таких данных
забавное решение, но одна из догм react это реиспользование компонентов. а это позволительно только в ситуации когда дочерние компоненты ничего не знают о родительских (i.e. не имеют зависимостей кроме props). flux придуман не просто так.
Pub/Sub выглядит более гибким, и главное легальным, механизмом обмена данными между уровнями компонентов.
Бесспорно, но в глупых компонентах, которые в самом низу в иерархии не должно быть обращений к стору, поэтому хотя бы для таких компонентов контекст имеет место быть.
PubSub? Это когда дочерний компонент лезет к глобальной переменной за регистрацией?
да. только не обязательно глобальной. доступной обоим компонентам, между которыми нужно расшарить данные.
Ну а как вы можете снаружи настроить, в какой паб-саб и по какому пабу и сабу компонент будет общаться?
Паб-саб это в чистом виде глобальная переменная.
Паб-саб это в чистом виде глобальная переменная.
вы правы, по сути, это я к словам придираюсь, что с современными возможностями (говорю про browserify и любой другой dep manager) store не обязательно будет в глобальной переменной. всё приложение чаще всего внутри анонимной функции :) но сути вопроса это не меняет, да.
Вы сейчас говорите о том, что стор будет переменной, переданной снаружи. Но ведь нельзя снаружи компонента управлять тем, откуда эта переменная будет получена.
В ангуляре можно (dependency injection), в Flux нельзя. Flux это плохо и неправильно.
Плюс к этому Flux выкидывает в помойку половину того, что есть в реакте, отказываясь от props
В ангуляре можно (dependency injection), в Flux нельзя. Flux это плохо и неправильно.
Плюс к этому Flux выкидывает в помойку половину того, что есть в реакте, отказываясь от props
Вам впору статью писать о плюсах/минусах AngularJS и React/Flux с точки зрения архитектуры приложения. Наконец-то может получиться интересный обзор от того, кто более-менее глубоко работал и с тем и с тем. А то обычно какой-то перекос, когда обзор пишет человек, который с одним инструментом работал долго и глубоко, а второй попытался освоить за недельку.
немного не понял, причём здесь то, откуда и чем управлять. я всего лишь утверждаю, что с современными инструментами, какой-нибудь PostsStore не будет являться property объекта window, а будет переменной, расшаренной только компонентам, которые этот store require-нули внутри анонимной функции.
Вы всё правильно написали, это хорошая штука.
Флюксы-шмуксы это не решение, а временный запил от непонимания того, как именно жить с реактом в продакшне. Вот одну идею сделали, а остальные её составляющие не продумали.
Вроде всё хорошо началось: немутабельные контролы, асинхронный setState, а потом фигак и глобальные переменные на которые надо подписываться. Это, конечно, зло. Основная идея немутабельного и чистого подхода в том, что тот, кто владеет компонентом, может полностью управлять его поведением.
Как можно управлять поведением, если компонент сам шастает по глобальным переменным и чего-то там делает, я не понимаю.
Флюксы-шмуксы это не решение, а временный запил от непонимания того, как именно жить с реактом в продакшне. Вот одну идею сделали, а остальные её составляющие не продумали.
Вроде всё хорошо началось: немутабельные контролы, асинхронный setState, а потом фигак и глобальные переменные на которые надо подписываться. Это, конечно, зло. Основная идея немутабельного и чистого подхода в том, что тот, кто владеет компонентом, может полностью управлять его поведением.
Как можно управлять поведением, если компонент сам шастает по глобальным переменным и чего-то там делает, я не понимаю.
Так компонент не должен шастать нигде, глупые компоненты управляются владельцем на основе props. PubSub не подходит тут.
А как вы разделяете глупые и умные компоненты?
В разных папках держу) умные обращаются к стору, глупые получают данные через пропс и контекст.
Тоже вариант, но это всё попытки ad-hoc придумать как же жить с реактовским подходом в реальной жизни.
Уважаемый, вы либо троллите, либо заблуждаетесь. Само понятие глупый подразумевает незнание. Чтобы получить что-то в контекст, это что-то нужно попросить.
Глупый компонент — это компонент имеющий пропсы, редко стейт (на пример кастомный checkbox). Но никак не контекст.
Глупый компонент — это компонент имеющий пропсы, редко стейт (на пример кастомный checkbox). Но никак не контекст.
Подходит. Делаете глупый компонент, зависящий только от props, и умный, в котором делаете PubSub к чему угодно. Не обязательно все-все смешивать в одном компоненте.
Теперь я понял что имел ввиду Дэн Абрамов в этой тудушке
React.render(
// The child must be wrapped in a function
// to work around an issue in React 0.13.
<Provider store={store}>
{() => <App />}
</Provider>,
rootElement
);
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мир недокументированного React.js. Context