Redux: Как вызывать действия без использования @connect?

Я не уверен, что это «правильный» способ или нет, но вы можете получить доступ к магазину через контекст. См., Например, компонент Connector :
https://github.com/gaearon/react-redux/blob/master/src/components/createConnector.js

Я не слежу за тобой. Я отлично получаю доступ к магазину с помощью @connect. Я ищу способ связать / вызвать действия в компоненте без использования @connect.

Функция dispatch - это метод магазина. Если он вам нужен в вашем компоненте, но вы не хотите использовать @connect , вы можете получить доступ к хранилищу через контекст и использовать его метод отправки:

class MyComponent extends Compoenent {
    static contextTypes = {
        store: React.PropTypes.object.isRequired,
    }

    render() {
         const { dispatch } = this.context.store
         const actions = bindActionCreators(headerActions, dispatch)
    }
}

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

Спасибо, что объяснили это! Я понял теперь.

Вы можете передать dispatch этому компоненту вручную как опору.

Я тоже немного озадачен этим вопросом.

Если я правильно понимаю, нам нужно либо иметь dispatch доступное через props компонента (чтобы иметь возможность отправлять действия из этого компонента), либо предоставить создателям действий, уже привязанным к dispatch , из родительский компонент. Но оба решения требуют наличия родительского компонента connect ed, чтобы диспетчеризация была доступна ему через его свойства.

Итак, в конце мы просто переносим нашу зависимость dispatch на родительский компонент. И как бы вы это сделали, если такого родителя connect ed нет?

Например, что, если бы мы были в глубокой иерархии компонентов:

Provider
  Router
    AppContainer
     ...
       ...
         ...
           TheComponentThatNeedDispatch

а если никому из родителей не нужно подключаться к состоянию редукции?

Доступность диспетчеризации для компонента в качестве побочного эффекта от использования connect похоже, ставит нас в ситуацию, когда одним из его родителей является connect ed. может dispatch действие. Это кажется странным, поскольку не должно быть никакой корреляции между способностью компонента выполнять dispatch действие и необходимостью использовать connect для чтения из состояния redux.

Я знаю, что мы все еще можем получить доступ к dispatch из контекста компонента (через store.dispatch ), но поскольку это не рекомендуется ...

Что вы думаете об этом?

Благодаря!

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

Почему это странно? Думайте о connect как о «подключении к Redux», а не просто о «подключении к части состояния Redux». Тогда это имеет смысл: чтобы иметь возможность dispatch либо сам компонент, либо его родительский компонент, должен быть connect() ed для Redux.

С текущим React Redux API неудобно подключаться к Redux без выбора состояния. Вам нужно будет написать что-то вроде connect(state => ({}))(MyComponent) (вернуть пустой объект). Вот почему мы изучали для него dispatch первоклассным гражданином, и планируем добавить API для захвата «только dispatch ».

Имеет ли это смысл?

Думайте о подключении как о «подключении к Redux», а не просто «подключитесь к части состояния Redux».

Теперь это имеет смысл :).

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

Большое спасибо, использование Redux - это блаженство!

Это доступно на https://github.com/gaearon/react-redux/releases/tag/v0.5.0.

Выглядит отлично!

@gaearon, эй, Дэн, можешь дать мне совет о том, как использовать bindActionCreators с вложенными компонентами:

"AddProduct" - подключен к redux (см. Ниже)
__ "Список товаров"
____ «ProductView».

Я хочу, чтобы ProductView могла отправлять, но только в главном «Добавить продукт» есть:

function appState(state) {
    return {...};
}

export default connect(appState)(AddProduct)

Вы можете либо connect() вложенный компонент, либо вы можете передать ему dispatch в качестве опоры.

спасибо Дэн, очень ценю вашу помощь. тоже очень люблю redux!

другой вопрос, если можно:
Могу ли я размещать запросы на публикацию серверного API изнутри самого редуктора?
когда я отправляю сообщение в базу данных (mongodb), элемент получает «_id», который я хотел бы иметь в моем состоянии redux. следует ли отправлять отправку в качестве обратного вызова для запроса POST?

благодарю вас

Могу ли я размещать запросы на публикацию серверного API изнутри самого редуктора?

Определенно нет, редукторы должны быть чистыми функциями без каких-либо побочных эффектов.

когда я отправляю сообщение в базу данных (mongodb), элемент получает «_id», который я хотел бы иметь в моем состоянии redux. следует ли отправлять отправку в качестве обратного вызова для запроса POST?

Да.

См. Это руководство: http://rackt.github.io/redux/docs/advanced/AsyncActions.html

спасибо Дэн, отлично работает (у)

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

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

Вы можете создать хранилище на сервере, дождаться завершения асинхронных действий и затем выполнить рендеринг.
См. Также http://rackt.github.io/redux/docs/recipes/ServerRendering.html.

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

@mpoisot : потому что вам нужно будет знать, импортировать, связывать и распространять _ каждого_ потенциального создателя действий при запуске приложения. Помимо прочего, это не помогает в таких ситуациях, как разделение кода.

@markerikson Мне уже нужно знать все редукторы при инициализации приложения, поэтому я могу вызвать createStore . Я представляю, как позвонить bindAllActionCreators(store.dispatch) на следующей строке.

Правда, вы можете получить немного больше кода, чем используете на самом деле. Но если это вызывает беспокойство, не делайте этого. Или разбейте свои наборы редукторов (редукторы + создатели действий + селекторы) на более мелкие и более сфокусированные пакеты. Или привяжите только некоторых создателей действий.

Есть ли за это ужасное снижение производительности? Или это как-то ведет ужасный путь к аду кодирования?

@mpoisot : на самом деле я не могу придумать никаких проблем с производительностью. Однако это ограничивает возможность тестирования и повторного использования.

Правильное использование connect приводит к легкому подходу к внедрению зависимостей. «Обычный» компонент знает только о том, что ему дается некоторая функция в качестве опоры, и он должен вызывать эту функцию по мере необходимости. На самом деле его не волнует, был ли это обратный вызов, который был передан напрямую некоторым родительским компонентом, или создателем предварительно связанного действия. Это означает, что компонент может быть повторно использован простым способом, а также значительно упрощает его тестирование. С другой стороны, выполнение чего-то вроде прямого импорта магазина приводит к привязке компонента к этому конкретному экземпляру и реализации магазина, поэтому это не рекомендуется (согласно часто задаваемым вопросам Redux: http://redux.js.org/docs/faq/ StoreSetup.html # store-setup-multiple-store). Если я правильно понимаю, о чем вы спрашиваете, это практически та же ситуация, что и при прямом импорте и обращении к магазину.

Хороший момент, частичное применение диспетчера в действии создателей было бы эквивалентно импорту магазина как синглтона, что не одобряется. Я попытался понять, почему, и нашел несколько мест, где Дэн Абрамов сказал, что одноэлементный магазин не одобряется из-за рендеринга на стороне сервера (который большинство людей никогда не будет использовать), но, как ни странно, он никогда не упоминал тестирование (которое все должны делать, или, по крайней мере, чувствовать себя плохо из-за того, что не делаю).

Что заставляет меня думать, конечно, вы можете создать одноэлементный объект хранилища, хранилище которого можно обновлять с помощью разных хранилищ для тестирования? Вместо прямого экспорта самого магазина верните его через StoreSingleton.getStore() и измените текущий магазин через StoreSingleton.setStore() . Таким образом, с точки зрения тестирования вы не будете привязаны к одному экземпляру магазина. Однако я понимаю, почему это не работает в среде многопоточного сервера.

@mpoisot Вы только что описали, что делает Provider / connect. ;)

Часто у меня есть «тупой» компонент, который однажды нужно отправить (или предварительно связать действие). Так что я оборачиваю его в connect или, может быть, передаю информацию из подключаемого компонента. Часто кажется, что много проводов и пропущенных реквизитов просто необходимо, чтобы избежать глобально доступной рассылки. Для mapStateToProps () есть замечательный прирост производительности с Provider / connect (). А для повторного использования «глупых» компонентов определенно имеет смысл извлечь логику отправки в компонент более высокого порядка.

Но я использовал этот сценарий достаточно раз, чтобы задаться вопросом, почему. И, похоже, ответ - «так что вы когда-нибудь сможете выполнять рендеринг на стороне сервера». (Пожалуйста, поправьте меня, если я ошибаюсь).

Прямо сейчас connect() просто дает вам метод dispatch из магазина Provider , но в будущем, возможно, это может измениться. Мы могли бы добавить дополнительную функциональность, например, интеграцию с инструментами разработчика, чтобы сообщить вам, какой компонент React был источником срабатывающего действия. Или кто-то может создать компонент, улучшающий хранилище другим способом, взяв хранилище в контексте, каким-то образом улучшив его, а затем передав это расширенное хранилище вниз по дереву компонентов. Если вы привязали создателей действий к одноэлементному магазину, вы потенциально могли бы вызвать неправильный dispatch .

Да, некоторые из экспериментов "компонент / инкапсулированное состояние", которые я видел, работают именно с этим подходом. Замечательная особенность этой идеи заключается в том, что другим компонентам не нужно знать, что что-то изменилось, поскольку компоненты оболочки все еще просто захватывают this.context.store и используют его dispatch мере необходимости.

Я был по обе стороны от этого -

В моем основном приложении мы рассматриваем хранилище как синглтон и используем глобально доступную функцию getStore() . Мы не используем рендеринг на стороне сервера. Мы по-прежнему используем Provider и connect для mapStateToProps .

С другой стороны, я создал экспериментальное приложение, в котором я оборачиваю магазин (например, @jimbolla и @markerikson ) в различные места в иерархии компонентов, и оба dispatch и getState могут изменяются во всем приложении, что означает, что они _должны_ быть подключены ко всему приложению (через context или props ) и не могут быть одиночными.

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

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

Спасибо, отличный отзыв. Может ли кто-нибудь опубликовать ссылку, демонстрирующую упаковку магазина?

@mpoisot

Вот один из комментариев Дэна, который показывает, как упаковка dispatch может быть полезной:

https://github.com/reactjs/redux/issues/822#issuecomment -145271384

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

В частности, обратите внимание на то, как упакован dispatch (я его выделил):

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

export default class App extends Component {
...
  componentDidMount() {
    //registering event listener
    BackgroundGeolocation.on('location', this.onLocation, this.onError);
  }

  onLocation(location) {
   //wishing to dispatch an action to update variable in store
  }

  render() {
    return (
      <Provider store={store}>
        <AlertProvider>
          <MainNavigator screenProps={{ isConnected: this.state.isConnected }} />
        </AlertProvider>
      </Provider>
    );
  }
}

Насколько я понимаю, я не могу подключиться к хранилищу в этом компоненте, поскольку мы просто настраиваем и передаем хранилище в Provider . Как я могу отправить действие в моем событии onLocation ?

@isaaclem : ну, в этом конкретном случае у вас _do_ есть ссылка на магазин, поэтому вы можете просто напрямую вызвать store.dispatch(someAction) .

Другой вариант - реструктурировать структуру вашего компонента так, чтобы какой-то компонент _inside_ <Provider> выполнял фоновое поведение геолокации и также мог быть подключен.