Мир недокументированного React.js. Context

[@DeLaVega]

Интересно, а если данные, положенные в getChildContext не статичные, а подтягиваются из стора. И в случае, если данные изменились, то в дочерних элементах все автоматически обновится или нужно что-то на подобии componentWillReceiveProps?

[@hell0w0rd]

Но самый элегантный путь — это использование контекста.

По рукам надо за такое бить. Не документированная фича — это не просто так, что разработчики забыли. Это очень спорная фича, не до конца реализованная и не факт, окажется ли она в 1.0, или будет точно такой же в следующих релизах.

[@WebApelsin]

Разработчики заявляли, что эта фича войдет в 1.0 и будет допилена и задокументирована. К сожалению, под рукой нет пруфа.

[@Arilas]

Context'ы — задокументированная фича, но не полностью, тот же React Router работает как раз на основании контекстов. Но дальше чем роутинг, я бы контекстами не пользовался, иначе получим проблему скоупов от Ангуляра. Проще уж Стор сделать для таких данных

[@erlyvideo]

скоупы ангуляра весело позволяют и подталкивают к тому, что бы организовывать коммуникацию соседних компонент через общий скоуп

[@hell0w0rd]

RR отказывается от контекстов в версии 1.0, на сколько мне известно.

[@turbo_exe]

забавное решение, но одна из догм react это реиспользование компонентов. а это позволительно только в ситуации когда дочерние компоненты ничего не знают о родительских (i.e. не имеют зависимостей кроме props). flux придуман не просто так.

[@Staltec]

Pub/Sub выглядит более гибким, и главное легальным, механизмом обмена данными между уровнями компонентов.

[@webMarshal]

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

[@erlyvideo]

PubSub? Это когда дочерний компонент лезет к глобальной переменной за регистрацией?

[@turbo_exe]

да. только не обязательно глобальной. доступной обоим компонентам, между которыми нужно расшарить данные.

[@erlyvideo]

Ну а как вы можете снаружи настроить, в какой паб-саб и по какому пабу и сабу компонент будет общаться?

Паб-саб это в чистом виде глобальная переменная.

[@turbo_exe]

вы правы, по сути, это я к словам придираюсь, что с современными возможностями (говорю про browserify и любой другой dep manager) store не обязательно будет в глобальной переменной. всё приложение чаще всего внутри анонимной функции :) но сути вопроса это не меняет, да.

[@erlyvideo]

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

В ангуляре можно (dependency injection), в Flux нельзя. Flux это плохо и неправильно.

Плюс к этому Flux выкидывает в помойку половину того, что есть в реакте, отказываясь от props

[@aav]

Вам впору статью писать о плюсах/минусах AngularJS и React/Flux с точки зрения архитектуры приложения. Наконец-то может получиться интересный обзор от того, кто более-менее глубоко работал и с тем и с тем. А то обычно какой-то перекос, когда обзор пишет человек, который с одним инструментом работал долго и глубоко, а второй попытался освоить за недельку.

[@erlyvideo]

Да, постараюсь =)

Мы и с тем, и с тем поработали.

[@turbo_exe]

немного не понял, причём здесь то, откуда и чем управлять. я всего лишь утверждаю, что с современными инструментами, какой-нибудь PostsStore не будет являться property объекта window, а будет переменной, расшаренной только компонентам, которые этот store require-нули внутри анонимной функции.

[@erlyvideo]

компонент сам заказывает, откуда ему взять PostsStore. Ему не передали его сверху, а он сам его нашел. Это и называется глобальная переменная

[@erlyvideo]

Вы всё правильно написали, это хорошая штука.

Флюксы-шмуксы это не решение, а временный запил от непонимания того, как именно жить с реактом в продакшне. Вот одну идею сделали, а остальные её составляющие не продумали.

Вроде всё хорошо началось: немутабельные контролы, асинхронный setState, а потом фигак и глобальные переменные на которые надо подписываться. Это, конечно, зло. Основная идея немутабельного и чистого подхода в том, что тот, кто владеет компонентом, может полностью управлять его поведением.

Как можно управлять поведением, если компонент сам шастает по глобальным переменным и чего-то там делает, я не понимаю.

[@webMarshal]

Так компонент не должен шастать нигде, глупые компоненты управляются владельцем на основе props. PubSub не подходит тут.

[@erlyvideo]

А как вы разделяете глупые и умные компоненты?

[@webMarshal]

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

[@erlyvideo]

Тоже вариант, но это всё попытки ad-hoc придумать как же жить с реактовским подходом в реальной жизни.

[@hell0w0rd]

Уважаемый, вы либо троллите, либо заблуждаетесь. Само понятие глупый подразумевает незнание. Чтобы получить что-то в контекст, это что-то нужно попросить.
Глупый компонент — это компонент имеющий пропсы, редко стейт (на пример кастомный checkbox). Но никак не контекст.

[@webMarshal]

Компонент, который в самом низу иерархии, но зависит от контекста — не является глупым? Данный в него передавать нужно через props или не пытаться иметь внизу иерархии глупый компонент?

[@dfuse]

Подходит. Делаете глупый компонент, зависящий только от props, и умный, в котором делаете PubSub к чему угодно. Не обязательно все-все смешивать в одном компоненте.

[@dfuse]

www.youtube.com/watch?v=KYzlpRvWZ6c&t=1351 вот видео
medium.com/@learnreact/container-components-c0e67432e005 вот статья

[@NeXTs_od]

Теперь я понял что имел ввиду Дэн Абрамов в этой тудушке

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
);