Redux: Время Redux пришло и прошло

https://github.com/rackt/redux/issues/464

Многие люди очень довольны Redux. Вы должны поспрашивать - я не совсем квалифицирован, чтобы ответить на этот вопрос. Я бы сказал, что если ваше приложение очень загружено данными, как Facebook (много вложенных сущностей со сложными отношениями), неплохо было бы инвестировать в бэкэнд GraphQL и изучить Relay. Я слышал об этом только хорошее.

Redux, конечно, более явный и не решает за вас декларативную выборку данных. Есть попытки интегрировать Redux и GraphQL, но я не могу

Redux намного ниже уровня Relay, и он не более «прошлое», чем простые объекты JS и функции «прошлого». Relay - это фреймворк, а Redux, без проверок работоспособности, представляет собой десять 10-строчных функций, поэтому неудивительно, что у них разные области действия. Выберите то, что лучше всего подходит для вас, и дайте нам знать.

Декларативная загрузка GraphQL потрясающая, первоклассная. Однако Relay по-прежнему имеет в основном HoC API, который сам по себе не является декларативным. Если бы Relay предлагал более гибкий API, не связанный с деревом компонентов, тогда можно было бы написать правильную привязку Redux?

Я думаю, что это 2 типа систем, которые решают 2 разные проблемы.
Этот билет похож на вопрос плотников, не прошло ли время молота.
Системы на основе graphql, я бы сказал, являются чрезмерно спроектированным решением для многих приложений, и наоборот, приложения со сложными структурами данных, скорее всего, будут недостаточно спроектированы, если построены с использованием redux.

Системы на основе graphql, я бы сказал, являются чрезмерно спроектированным решением для многих приложений, и наоборот, приложения со сложными структурами данных, скорее всего, будут недостаточно спроектированы, если построены с использованием redux.

Хороший способ выразиться; я тоже так к этому отношусь.

@gaearon, продолжайте в том же

@gaearon, продолжайте в том же

: 100:

я думаю, что они не то же самое:

• relay - для решения управления загрузкой данных с сервера
• redux - для решения управления состоянием приложения

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

Вопрос в том, как Relay соотносится с шаблонами проектирования, вдохновленными потоком? Где заканчивается Relay, когда нам нужен Redux? Relay Flux 2.0?

Пример Todo Relay: делает redux устаревшим?

Может быть, есть способ сообщить вашему редуктору, как и когда сопоставлять себя с GraphQL и обратно? Не говоря о несложных вещах, но каков самый простой способ придать этому смысл.

Необходимо узнать больше о том, что такое реле. Это точно не пара сотен строк кода!

@oriSomething Вы не совсем правы. Relay также решает многие задачи по управлению состоянием.

@gyzerok я имел в виду состояние приложения на стороне клиента

@oriSomething Да, я говорю о состоянии клиентского приложения

@gyzerok , должно

@oriSomething нет специальной ссылки, потому что Relay управляет ею неявно. Может быть, вы можете попробовать посмотреть, как FB рассказывает о Relay. Они говорят о том, как Relay решает проблему с кешем. Кэш клиентского приложения = состояние. Определенного разговора не помню, извините.

@oriSomething - единственное место, где разработчик должен делать явное управление состоянием, - это здесь .

@gyzerok хорошо, в таком случае есть ли управление состоянием, не связанное с сервером, который выполняет реле? Насколько я понимаю, нет, или нет?

@oriSomething Если я правильно вас понял, Relay выполняет все действия по нормализации данных на клиенте и объединяет данные из запросов в единое хранилище.

@oriSomething да, есть => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Проверьте: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Только если данных на клиенте недостаточно, Relay отправляет запрос на сервер для получения дополнительных данных.

Redux намного ниже уровня Relay, и он не более «прошлое», чем простые объекты JS и функции «прошлого». Relay - это фреймворк, а Redux, без проверок работоспособности, представляет собой десять 10-строчных функций, поэтому неудивительно, что у них разные области действия.

Так что я сделал slim-redux.js просто для удовольствия - версию Redux без комментариев, предупреждений разработчиков и проверок работоспособности. Он проходит все необходимые тесты Redux (кроме тестов на работоспособность), и это 99 строк: wink:. Это должно подтвердить мою точку зрения о том, что Relay и Redux - это инструменты с совершенно разными областями применения.

@IwanKaramazow, я думаю, я не достаточно

@oriЧто-нибудь можно привести пример?

Полностью согласен с @mattapperson . Все сводится к определению сложного, или, лучше сказать, к тому, где каждый человек распознает «сложную вещь».

@IwanKaramazow Я думаю, что @oriSomething говорит, например, о состоянии формы на стороне клиента

Я перешел с Redux => Relay из-за GraphQL. В основном все ресурсы в моем приложении были иерархическими. Естественно, они имели смысл быть вложенными сущностями. Хранить кеш этих моделей в Redux было потрясающе. У меня был разумный взгляд на свои данные, и я мог быстро выполнить итерацию с помощью потрясающих redux-devtools.

Но без GraphQL мне пришлось сделать несколько циклов, чтобы сопоставить удаленные ресурсы с деревом редукции.

1. / resource1-list
2. / ресурс2-список? ресурс1 =
3. / resource3-list? resource2 =

Очевидно, это проблема REST, а не Redux. Если бы я раньше видел некоторые привязки Redux-GraphQL, возможно, я бы их использовал. В моем приложении Adopting Relay практически не изменился. Вместо @connect я использую Relay.createContainer . Оба продукта имеют одинаковое видение архитектуры с разными API. Я написал об этом небольшой пост .

В настоящее время я использую как redux, так и relay / graphql, и хотя relay отлично подходит для выборки данных, я всегда вижу себя использующим redux. В настоящее время я использую redux по двум причинам, и я вижу, что в будущем найду больше причин.

1) Разное состояние, которое необходимо разделить между компонентами, которые не находятся в базе данных
2) Форма подготовки. На самом деле у меня есть одна часть моего приложения, где у меня есть компонент панели инструментов с кнопкой отправки и компонент панели, который содержит все мои поля ввода. Когда я набираю форму, я отклоняю свой ввод в «редуктор формы», хранящийся в redux, чтобы моя панель инструментов могла иметь доступ к данным перед отправкой.

Кроме того, redux devtools великолепен.

Блин, боже. Я читал сегодня о Relay и должен признать, что код нелегко читать и непросто для понимания. Я просмотрел несколько примеров Redux и смог понять основные концепции, просто прочитав код.

Учебник или пример Todo не кажутся элегантными. Я думаю, что React и FLUX гордятся своей простотой. Я пока не чувствую этого чувства от Relay.

Учитывая тесную связь Relay с React и относительную чрезмерную сложность большинства приложений, в последнее время я больше увлекся Falcor. Фактически, благодаря интерфейсу, основанному на обещаниях, он очень хорошо подходит для большинства асинхронных действий в Redux. А поскольку он отделен от React, мне легче использовать его повсюду в своем приложении. Кроме того, рендеринг на стороне сервера еще не полностью запечен , что для меня

Мне также нравится реагирующий преобразователь , который в некотором роде похож на "Relay Lite". Этот вариант может оказаться лучшим для очень простых проектов или тех, которые полагаются на сторонние REST API.

@timdorr Вы пытались сохранить все свое состояние в Falcor? Например, ваши редукторы используют объект Falcor.

Еще нет. Я все еще нахожусь в экспериментальном режиме с этим, и у меня есть более крупная рыба, чтобы поджарить мои проекты, поэтому я еще не уделил этому достаточно внимания.

Я играл с Falcor и очень рекомендую его. Фактически, я сейчас работаю над интеграцией приложения Redux с серверной частью Falcor. Он не предоставляет вам агрегацию запросов Relay, но в его клиентской библиотеке есть очень сложный уровень кеширования, который предотвращает избыточную выборку. Думаю, этого может быть достаточно, но время покажет.

@gaearon, как написание веб-приложения React с декларативной

Мне кажется, что главное отличие состоит в том, что выборка данных более декларативна с Relay и GraphQL (Elm просит вас указать URL-адрес, и вам решать, какие данные возвращаются), а все остальное более декларативно в Elm .

На самом деле, похоже, что экосистема Elm могла бы выиграть от переноса Relay / GraphQL.

Что касается агрегирования запросов, существует метод Model.batch . Это занимает либо интервал (в миллисекундах), либо планировщик, но я не нахожу много документации по планировщикам.

Если вы не возражаете, я спрошу, как вы интегрируете Redux и Falcor? Все мои попытки оставили меня разочарованным.

Мне также было бы интересно увидеть пример Redux Falcor. Я прочитал все документы Falor и согласен, что это намного проще, чем relay / graphql. Хотя и менее мощный.

Для тех, кто интересуется связью Redux с Relay и имеет ли смысл использовать их вместе, см .: https://github.com/facebook/relay/issues/114

Суть в том, что Relay в конечном итоге будет обрабатывать данные из нескольких источников (бэкэнд, локальные эфемерные данные и т. Д.), Поэтому он заменяет другие реализации Flux, которые вы можете использовать.

https://github.com/facebook/relay/issues/168#issuecomment -135169255:

Обратите внимание, что Relay - это реализация шаблона Flux (может ли Flux заменить себя? ;-).

В OpenGov мы активно используем как Redux, так и Relay. Это правда, что после перехода на Relay наша папка reducers/ стала намного меньше. Однако мы обнаружили, что Redux по-прежнему весьма полезен для управления локальным состоянием на уровне приложений. Возможно, однажды Relay вытеснит его и в этой области. Но, как однажды сказал @josephsavona , "архитектура Redux" на самом деле просто ... функции :) Даже если однажды вы откажетесь от библиотеки Redux, вы, вероятно, продолжите использовать неизменяемые обновления состояния, реактивный поток данных, редуктор функции и т.д. на обозримое будущее. Это ценная часть Redux IMO, не обязательно <100-строчная библиотека, которая существует в этом репо. (Да, и сообщество, конечно.)

Я бы сказал, что если ваше приложение очень загружено данными, как Facebook (много вложенных сущностей со сложными отношениями), неплохо было бы инвестировать в бэкэнд GraphQL и изучить Relay.

Согласен, но я бы сказал, что GraphQL + Relay - хорошее вложение даже для приложений небольшого размера, особенно для новых проектов, которые начинаются с нуля.

Что вы, ребята, думаете о https://github.com/gyzerok/adrenaline?

Не совсем подходит, потому что он не использует Relay, но что вы думаете об этом самоуверенном подходе со стороны сообщества Meteor? https://github.com/mattkrick/meatier

Только глубокая архитектура, такая как GraphQL / Relay или Datomic / Om.Next, может решить проблему объектного / реляционного импеданса ... Вот мои мысли - обратная связь приветствуется.

GraphQL / Relay: конец Redux?

Похоже, эта тема интересует многих (Relay / Redux, GraphQL и снижение сложности). Я работаю над дизайном простого, но функционального клиента GraphQL, который будет очень хорошо сочетаться с подходом Redux к состоянию приложения.

Любопытно, что люди думают об этом наборе принципов дизайна: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Просто добавляю сюда мои 2cents: я не думаю, что Redux закончится. Это просто и красиво, и во многих случаях достаточно. Экосистема JS настолько быстра, и за ней сложно успевать, и Redux, как и React в некотором роде, является важной вехой, на которую мы можем положиться в течение некоторого времени. Мы просто не можем развивать наш рабочий процесс каждый месяц (по крайней мере, я не могу), и я думаю, что Redux - действительно хороший вариант прямо сейчас. Ретрансляция (и получение данных в целом) просто не требуется во многих проектах ...

@gaearon , прошло несколько месяцев с тех пор, как вы

@likeabbas, если вы ищете интеграцию GraphQL-Redux, попробуйте Apollo Client: http://docs.apollostack.com/apollo-client/index.html

У нас еще нет 100% паритета функций с Relay, но мы приближаемся.

@gaearon, чтобы повторить вопрос @likeabbas : «Где мы сейчас находимся с точки зрения интеграции GraphQL с Redux по сравнению с Relay / или, возможно, комбинацией всех трех?»

Пара кратких мыслей. Redux - это общий фреймворк, который обеспечивает баланс между достаточной структурой и достаточной гибкостью. Таким образом, он предоставляет разработчикам платформу для создания настраиваемого управления состоянием для своих сценариев использования, при этом имея возможность повторно использовать такие вещи, как графический отладчик или промежуточное ПО. Этот вариант использования вряд ли исчезнет, ​​поэтому вместо того, чтобы «время Redux пришло и прошло», возможно, более интересным будет вопрос: если вы создаете клиент GraphQL, имеет ли смысл строить на Redux?

На что я бы ответил, что неясно, есть ли один правильный ответ. Создание на основе Redux может выиграть от интеграции (общие инструменты, общие данные), в то время как создание индивидуального подхода требует больше усилий, но позволяет использовать больше инструментов для конкретной предметной области и может повысить производительность. Как и многое другое в разработке программного обеспечения, это зависит от варианта использования!

@josephsavona : это отличное резюме Redux! Возможно, нам придется где-нибудь украсть это для документации :)

Да, название этой ветки не оптимально, и похоже, что вопрос уже исчерпан. Возможно, пора перенести дискуссию в другое место.

>.> lock the issue

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

Упс, не та кнопка. Извините за это 😄