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

상위 구성 요소에서 디스패치를 ​​전달하거나 이미 디스패치에 바인딩 된 작업을 전달해야합니다. 그것이 _the_ 내가 믿는 방식입니다. 컨텍스트도 작동하지만 해결 방법입니다.

설명해 주셔서 감사합니다! 이제 이해가된다.

dispatch 를 해당 구성 요소에 수동으로 소품으로 전달할 수 있습니다.

나도이 문제에 대해 약간 의아해합니다.

내가 올바르게 이해했다면, 컴포넌트의 props를 통해 dispatch 사용하거나 (해당 컴포넌트에서 액션을 디스패치 할 수 있도록) 이미 dispatch 바인딩 된 액션 생성자에게 제공해야합니다. 부모 구성 요소. 그러나 두 솔루션 모두 해당 props를 통해 디스패치를 ​​사용할 수 있도록 connect ed 인 상위 구성 요소가 있어야합니다.

결국 우리는 dispatch 의 의존성을 부모 컴포넌트로 옮기는 것입니다. 그런 connect ed 부모가 없다면 어떻게할까요?

예를 들어, 우리가 구성 요소의 깊은 계층 구조에 있다면 어떻게 될까요?

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

부모가 redux 상태에 연결할 필요가 없다면?

connect 사용의 부작용으로 구성 요소에 디스패치를 ​​사용할 수있게되면 부모가 connect 이되도록하는 것이 전제 조건 인 상황에 놓이게됩니다. dispatch 작업을 수행 할 수 있습니다. dispatch 작업에 대한 구성 요소의 기능과 redux 상태에서 읽기 위해 connect 를 사용해야하는 필요성 사이에 어떤 상관 관계가 없어야하기 때문에 이것은 이상하게 느껴집니다.

구성 요소 컨텍스트 ( store.dispatch 를 통해)에서 여전히 dispatch 액세스 할 수 있다는 것을 알고 있지만 권장되는 방법이 아니기 때문에 ...

당신이 그것에 대해 어떻게 생각하십니까?

감사!

액션을 디스패치하는 컴포넌트의 능력과 redux 상태에서 읽기 위해 connect를 사용해야하는 필요성 사이에 어떤 상관 관계가 없어야하기 때문에 이것은 이상하게 느껴집니다.

왜 이상해? connect 을 단순히 "Redux 상태의 일부에 연결"이 아니라 "Redux에 연결"이라고 생각하십시오. 그런 다음 의미가 있습니다. 구성 요소 자체 또는 상위 구성 요소 중 하나를 dispatch 할 수 있으려면 Redux에 connect() ed가 있어야합니다.

현재 React Redux API를 사용하면 상태를 선택하지 않고 Redux에 연결하는 것이 편리하지 않습니다. connect(state => ({}))(MyComponent) (빈 객체 반환)와 같은 것을 작성해야합니다. 이것이 우리가 dispatch 일류 시민이되는 대체 API 를 dispatch "잡기위한 API를 추가 할 계획 인 이유입니다.

이게 말이 돼?

연결을 "Redux 상태의 일부에 연결"이 아니라 "Redux에 연결"이라고 생각하십시오.

이제 완전히 의미가 있습니다 :).

새로운 API 사용을 기다릴 수 없습니다.

감사합니다. Redux를 사용하는 것은 행복합니다!

https://github.com/gaearon/react-redux/releases/tag/v0.5.0 에서 사용할 수 있습니다

멋지네요!

@gaearon 안녕 Dan은 중첩 된 구성 요소와 함께 bindActionCreators를 사용하는 방법에 대한 팁을 줄 수 있습니다.

"AddProduct"-redux에 연결됨 (아래 참조)
__ "제품 목록"
____ "ProductView".

ProductView가 디스패치 할 수 있기를 원하지만 마스터 "제품 추가"에만 다음이 있습니다.

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

export default connect(appState)(AddProduct)

중첩 된 구성 요소도 connect() 하거나 dispatch 를 소품으로 전달할 수 있습니다.

감사합니다 댄, 도와 주셔서 감사합니다. redux도 정말 좋아합니다!

내가 할 수 있다면 또 다른 질문 :
감속기 내부에서 서버 API 게시 요청을 배치 할 수 있습니까?
데이터베이스 (mongodb)에 POST하면 항목이 redux 상태에서 원하는 "_id"를 얻습니다. 디스패치를 ​​POST 요청에 대한 콜백으로 배치해야합니까?

감사합니다

감속기 내부에서 서버 API 게시 요청을 배치 할 수 있습니까?

확실히 아닙니다. 감속기는 부작용이없는 순수한 기능이어야합니다.

데이터베이스 (mongodb)에 POST하면 항목이 redux 상태에서 원하는 "_id"를 얻습니다. 디스패치를 ​​POST 요청에 대한 콜백으로 배치해야합니까?

예.

이 가이드를 참조하십시오 : http://rackt.github.io/redux/docs/advanced/AsyncActions.html

감사합니다 Dan, 잘 작동합니다 (y)

서버 렌더링을 사용하는 경우 현재 사용자가 로그인하는 경우
스토어에서 비동기 가져 오기를 건너 뛰고 서버에서 수행 할 수 있습니까?

서버 렌더링을 사용하는 경우 현재 사용자가 로그인 한 상태에서 스토어에서 비동기 가져 오기를 건너 뛰고 서버에서 수행 할 수 있습니까?

서버에 저장소를 만들고 비동기 작업이 완료 될 때까지 기다린 다음 렌더링 할 수 있습니다.
http://rackt.github.io/redux/docs/recipes/ServerRendering.html 참조

나는 아마도 중요한 것을 놓치고 있지만 앱 초기화 중에 모든 액션 생성자에게 부분적으로 디스패치를 ​​적용하지 않는 이유는 무엇입니까? 그러면 디스패치에 대한 참조를 얻는 방법에 대해 걱정하지 않고 어디에서나 전화를 걸 수 있습니다.

@mpoisot : 앱 시작시 잠재적 인 액션 생성자를 알고, 가져오고, 바인딩하고, 배포해야하기 때문입니다. 무엇보다도 코드 분할과 같은 상황에서는 도움이되지 않습니다.

@markerikson createStore 호출 할 수 있도록 app init의 모든 감속기를 이미 알고 있어야합니다. 다음 줄에서 bindAllActionCreators(store.dispatch) 전화하는 것을 상상합니다.

사실, 실제로 사용하는 것보다 약간 더 많은 코드를 가져올 수 있습니다. 그러나 그것이 우려된다면 이런 식으로하지 마십시오. 또는 감속기 세트 (감속기 + 액션 제작자 + 선택기)를 더 작고 집중된 번들로 나눕니다. 또는 일부 액션 제작자 만 묶습니다.

이 작업에 대한 끔찍한 성능 저하가 있습니까? 아니면 어떻게 든 코딩 지옥으로가는 끔찍한 길로 이어질까요?

@mpoisot : 내가 생각할 수있는 성능 문제가 아닙니다. 그러나 테스트 가능성과 재사용 가능성을 제한합니다.

connect 올바르게 사용하면 간단한 종속성 주입 방식이 적용됩니다. "일반"구성 요소는 일부 기능이 소품으로 제공되고 있음을 알고 필요에 따라 해당 함수를 호출해야합니다. 일부 상위 구성 요소 또는 사전 바인딩 된 작업 생성자에 의해 직접 전달 된 콜백인지 여부는 실제로 중요하지 않습니다. 즉, 구성 요소를 간단하게 재사용 할 수 있고 테스트를 훨씬 쉽게 할 수 있습니다. 반면에 상점을 직접 가져 오는 것과 같은 작업을 수행하면 구성 요소가 해당 특정 상점 인스턴스 및 구현에 연결되므로 권장되지 않습니다 (Redux FAQ : http://redux.js.org/docs/faq/). StoreSetup.html # store-setup-multiple-stores). 내가 당신이 정확히 무엇을 요구하는지 이해한다면, 그것은 기본적으로 상점을 직접 가져오고 참조하는 것과 같은 상황입니다.

아 좋은 점, 액션 크리에이터의 디스패치를 ​​부분적으로 적용하는 것은 스토어를 싱글 톤으로 가져 오는 것과 같을 것입니다. 나는 그 이유를 알아 보려고 노력했고 Dan Abramov가 서버 측 렌더링 (대부분의 사람들이 절대 사용하지 않을 것)으로 인해 싱글 톤 스토어가 눈살을 찌푸리고 있다고 말했지만 이상하게도 그는 테스트에 대해 언급하지 않았습니다 (모두가해야 할 일 또는 적어도 하지 않는 것에 대해 기분이 나쁘다).

어떤 점에서 테스트를 위해 저장소를 다른 저장소로 업데이트 할 수있는 저장소 단일 객체를 만들 수 있다고 생각합니까? 스토어 자체를 직접 내보내는 대신 StoreSingleton.getStore() 를 통해 반환하고 StoreSingleton.setStore() 를 통해 현재 스토어를 변경합니다. 따라서 테스트 측면에서 단일 저장소 인스턴스에 묶이지 않습니다. 그러나 이것이 스레드 서버 환경에서 작동하지 않는 이유를 알 수 있습니다.

@mpoisot 방금 Provider / connect가 수행하는 작업을 설명했습니다. ;)

언젠가 디스패치 (또는 사전 바인딩 된 작업)가 필요한 "멍청한"구성 요소가 종종 있습니다. 그래서 나는 그를 연결로 감싸거나 연결된 구성 요소에서 물건을 전달할 수 있습니다. 전 세계적으로 접근 가능한 파견을 피하기 위해 많은 배선 및 전달 소품처럼 느껴지는 경우가 많습니다. mapStateToProps ()의 경우 Provider / connect ()로 놀라운 성능 향상이 있습니다. 그리고 멍청한 구성 요소를 재사용하려면 더 높은 순서의 구성 요소에 디스패치 논리를 추출하는 것이 좋습니다.

그러나 나는이 시나리오를 충분히 여러 번 쳐서 이유가 궁금합니다. 그리고 대답은 "언젠가 서버 측 렌더링을 할 수 있도록"입니다. (내가 틀렸다면 정정하십시오).

현재 connect() 는 Provider 의 상점에서 dispatch 메소드를 제공하지만 향후에는 변경 될 수 있습니다. 예를 들어 어떤 React 구성 요소가 실행중인 작업의 소스인지 알려주는 개발 도구와의 통합과 같은 추가 기능을 추가 할 수 있습니다. 또는 누군가가 컨텍스트에서 스토어를 가져 와서 어떻게 든 향상시킨 다음 향상된 스토어를 컴포넌트 트리에 전달하여 다른 방식으로 스토어를 향상시키는 컴포넌트를 만들 수 있습니다. 액션 제작자를 싱글 톤 스토어에 바인딩했다면 잠재적으로 잘못된 dispatch 호출 할 수 있습니다.

네, 제가 본 "구성 요소 / 캡슐화 된 상태"실험 중 일부는 정확히 그 접근 방식으로 작동합니다. 이 아이디어의 멋진 점은 래퍼 구성 요소가 여전히 this.context.store 잡고 필요에 따라 dispatch 를 사용하고 있기 때문에 다른 구성 요소는 변경된 사항을 알 필요가 없다는 것입니다.

나는 이것의 양쪽에 있었다-

내 기본 응용 프로그램에서 저장소를 싱글 톤으로 취급하고 전역 적으로 사용 가능한 getStore() 함수를 사용합니다. 우리는 서버 측 렌더링을 사용하지 않습니다. connect 대해 mapStateToProps Provider 및 connect 를 계속 사용합니다.

반면에 저는 구성 요소 계층 구조 내의 여러 위치에 스토어 ( @jimbolla 및 @markerikson 언급)를 래핑하는 실험용 앱을 구축했으며 dispatch 및 getState 즉, context 또는 props 를 통해 앱 전체에 연결되어야하며 싱글 톤이 될 수 없습니다.

달성하고 싶은 것에 따라 싱글 톤 스토어가 가능하다고 생각하지만 개인적으로는 천천히 멀어지고 있습니다.

네. 당신은 확실히 상점을 접근 가능한 싱글 톤으로 취급 할 수 있지만, 그것은 당신을 제한하고, 관용적 인 것으로 간주되지 않으며, 그렇게하는 것에 대한 실질적인 이점을 보지 못합니다.

감사합니다. 좋은 피드백입니다. 누군가가 상점 포장을 보여주는 링크를 게시 할 수 있습니까?

뿡뿡

다음은 dispatch 래핑이 유용 할 수있는 방법을 보여주는 Dan의 의견 중 하나입니다.

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> 가 백그라운드 위치 정보 동작을 수행하고 연결될 수 있도록 구성 요소 구조를 재구성하는 것입니다.