Redux: 컨테이너 대 구성 요소?

• 컨테이너 구성 요소
• 똑똑하고 멍청한 구성 요소

나를 위해 container 는 경로의 핸들러이며 해당 경로에 대한 redux의 상태도 가져옵니다. 그런 다음 내 상태를 소품으로 전달합니다.

예를 들면

container / properties.jsx

import React, { Component } from 'react';
import { bindActionCreators } from 'redux';
import { connect }  from 'react-redux';

import * as actions from 'actions/properties';
import Filter from 'components/properties/filter';
import List from 'components/properties/list';
import Pagination from 'components/properties/pagination';

class PropertiesContainer extends Component {
  render() {
    return (
      <section>
        <Filter filter={this.props.properties.params.filter} />
        <List items={this.props.properties.items} isFetching={this.props.properties.isFetching} />
        <Pagination pagination={this.props.properties.params.pagination} />
      </section>
    );
  }
}

function mapState(state) {
  const { properties } = state;

  return { properties };
}

function mapDispatch(dispatch) {
  return {
    actions: bindActionCreators(actions, dispatch),
  };
}

const Connector = connect(mapState, mapDispatch)(PropertiesContainer);

export default Connector;

예를 들어

components / properties / pagination.jsx

import React, { Component } from 'react';
import Pager from 'components/ui/pager';

class Pagination extends Component {
  render() {
    const { total, offset, limit } = this.props.pagination;
    const current = offset / limit;

    return (
      <Pager total={total} current={current} />
    )
  }
}

export default Pagination;

제공 한 링크에서 읽기 :

"A container does data fetching and then renders its corresponding sub-component. "

"컨테이너"가 실제로 redux에서 "스마트 구성 요소"라고 부르는 것 같은 느낌이 들었습니다. 경로 / 페이지는 자체 폴더를 가져야합니다.

"컨테이너"와 "라우트 처리기"가 어떤 식 으로든 관련되어있는 이유를 잘 모르겠습니다.

경로별로 앱 구성 요소를 그룹화하는 것은 매우 일반적인 관행입니다. @theaqua가 지적했듯이 각 경로 처리기 / 구성 요소를 스마트 / 컨테이너 구성 요소로 만드는 것도 일반적입니다. combineReducers를 사용하는 경우 동일한 라인을 따라 상태, 경로 및 컨테이너가 분리되는 경우가 많습니다. 따라서 그들은 종종 함께 연결됩니다.

@ronag 컨테이너 와 페이지를 만들 필요가 없다고 생각했습니다. 왜 라우트 핸들러와 redux 커넥터를 한곳에 놓을 수 없습니까? 매우 편리합니다. 단순하게 유지하십시오.

내 응용 프로그램에는 3 개의 경로 / 페이지 만 있습니다. 반면에 저는 많은 독립적 인 패널 / 모듈을 가지고 있습니다. 하나의 거대한 connect 만드는 것은 불가능합니다. 적어도 패널 측면에서 분할해야합니다.

상태에서 소품으로의 모든 매핑과 단일 파일에서 모든 데이터 가져 오기를 수행하면 유지 관리 할 수 ​​없습니다. 특히 모든 데이터를 동일한 위치에서 가져 오는 경우.

3 개의 경로가있는 경우 3 개의 경로 처리기가 필요합니다. 예를 들어 A.jsx 에서 B.jsx 및 C.jsx /containers .

각 컨테이너에서 redux 상태 및 작업 바인딩의 일부 (전체가 아님)를 가져옵니다. 그런 다음 이것을 내 예제와 같은 구성 요소에 전달합니다. 내가 (내 팀) 알고 있기 때문에, 매우 유지 보수의 - 연결 돌아 오는 항상에서 액션 바인딩하기 containers , 그것은 될 것 적도 components 내 예에서와 같이 종종 무 작고하는 ( ).

나는 당신의 제안을 이해한다고 생각합니다. 그러나 내가 말했듯이 모든 데이터 가져 오기를 거기에 넣으면 그 3 개의 파일이 매우 복잡해질 것입니다. 우리의 원인은 기본적으로 "Login, App, Logout"이며 App은 거의 모든 것을 포함합니다.

각 구성 요소에 가져올 데이터와 표시 방법을 설명하는 컨테이너가있는 Relay 너무 편향되어있을 수 있습니다.

나는 당신의 제안을 시도하고 우리가 끝나는 곳을 볼 것입니다.

나는 오직 props에 의해서만 구동되고 Redux와 대화하지 않는 캡슐화 된 React 컴포넌트를 components 라고 부릅니다. "단순한 구성 요소"와 동일합니다. 라우터, 데이터 가져 오기 라이브러리 등에 관계없이 동일하게 유지되어야합니다.

Redux, Router 등을 인식하는 React 구성 요소를 containers 라고 부릅니다. 이들은 앱과 더 많이 연결됩니다. "스마트 구성 요소"와 동일합니다.

@gaearon : 완벽합니다. 그 예가 명확 해집니다. 감사합니다.

@gaearon 따라서 "dumb 구성 요소"는 상태 비 저장 구성 요소로, React 0.14 이후 더 간단한 구문 으로 작성할 수 있습니다. 예를 들면 다음과 같습니다.

var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

제가 맞습니까?

@soulmachine 넵.

반드시 그런 것은 아닙니다. 구문은 요점이 아닙니다.

"Dumb"컴포넌트는 "presentational"컴포넌트라고도하며 props로 모든 데이터를 수신하고 Redux를 인식하지 않고 모양 만 지정하고 동작은 지정하지 않는 컴포넌트입니다.

@theaqua @gaearon 감사합니다!

"컨테이너"라는 용어는 react / redux 명명법에서 이미 꽤 인기가 있지만, 레이아웃 / 그래픽 컨테이너와의 혼동을 피하기 위해 제가 작업중인 프로젝트에서 "커넥터"라고 부르기로 결정했습니다.

btw, 그들을 호출하는 방법은 앞서 rackt / react-redux # 170에서 논의되었습니다. 모든 것을 components 폴더에 보관하고 프리젠 테이션 폴더는 components/presentational 안에 한 단계 더 깊게 보관합니다. 컨테이너가 아닌 앱의 일부에서 필요하지 않기 때문에 괜찮다고 생각합니다.

@gaearon dispatch "멍청한"또는 "스마트 한"것으로 간주되는 구성 요소입니까? 특히 디스패치를 ​​수행하기 위해 이벤트를 맨 위 구성 요소로 버블 링하는 대신 작업을 디스패치하는 리프 또는 중간 구성 요소를 갖는 것이 유용합니다.

예, connect() 이러한 구성 요소를 선호하지만 가끔 유용 할 수 있으므로 액션 제작자는 소품으로 주입됩니다. 어떻게 부르는지는 중요하지 않습니다. :-)

컴포넌트 모듈을 구축 할 때는 어떻습니까? 예를 들어 내비게이션 메뉴 <NavMenu> 대해 별도의 노드 모듈이 있다고 가정합니다. 사람들이 다음과 같은 코드를 작성하기를 원합니다.

import {NavMenu} from 'my-redux-aware-components';

export function myPage(props) {
  return (<div><NavMenu routes={props.routes} /></div>);
}

그래서 이름을 'NavMenuContainer'로 지정합니까? 그것은 나에게 이상해 보인다. 대신 구성 요소 이름을 NavMenuComponent로 지정해야합니까? 둘 다 나에게 이상해 보인다. 이 경우 구성 요소는 상태에서 하나의 필드를 가져 오기 위해 연결 만 호출합니다. 이렇게 연결하기 위해 호출을 인라인하는 것이 정말 나쁜가요?

export default const NavMenu = connect(state => ({currentPath:state.routing.path})(React.createClas({...}));

커넥트 콜을 인라인하는 것이 " 괜찮은 "때

어떻게 부르든 상관 없습니다. NavMenu 라고 부르지 않겠습니까?

인라인에 대한 질문을 이해하지 못합니다.
비교하는 두 가지 접근 방식을 제시하면 도움이 될 것입니다.

예를 들면 좋습니다.
옵션 1 (별도의 파일 2 개, 컨테이너 용 1 개, 구성 요소 용 1 개)

컨테이너 / NavMenu

import {connect} from 'react-redux';
import NavMenu from '../components/NavMenu';

export default connect(state => ({currentPath:state.routing.path})(NavMenu);

옵션 2 (둘 다 포함하는 단일 파일 1 개) :
구성 요소 / NavMenu

import {connect} from 'react-redux';

export default connect(state => ({currentPath:state.routing.path})(React.createClass({
  render() {
      return <div>the menu {this.props.currentPath} goes here</div>;
  }
});

내가 의미하는 것은 상태에서 필요한 currentPath에 대해 약간만 있기 때문에 컨테이너와 구성 요소 인 단일 파일 (2 개의 파일이 아닌)을 갖는 것입니다. 이것은 항상 피해야 할 일입니까, 아니면 이와 같은 간단한 경우에 수행하는 것이 합리적입니까?

물론 간단한 경우에이 작업을 수행하는 것이 합리적입니다.

그래요 좋아요. 언제 선을 그리고 "좋아, 이걸 2 개의 파일로 옮기 겠어"라고 말하겠습니까?

구성 요소가 데이터 문제 (데이터 검색 / 계산 방법, 작업 전달 방법)와 프레젠테이션 (모양)을 혼합하기 시작할 때. 다른 맥락에서 테스트하거나 재사용하기가 어려워 질 때.

@benmonro 한 가지 더 생각했습니다. 구성 요소 모듈을 빌드하는 경우 이러한 구성 요소를 앱 상태 트리의 다른 부분에 연결하거나 다양한 상태로 프레젠테이션을 개별적으로 테스트 할 수 있습니다. 이 경우이 구성 요소 모듈 내에 connect 있으면이 기능이 제한됩니다.

감사합니다 @gaearon

@sompylasar 아주 좋은 지적입니다! 감사

내 코드를 리팩토링하여 분리 한 후, 이제 후속 질문이 있습니다. <NavMenuItem> 컨테이너도 있다고 가정합니다. <NavMenu> 구성 요소는 <NavMenuItem /> 를 하위 요소로 참조해야합니다. NavMenu 구성 요소에서 import NavMenuItem from '../containers/NavMenuItem' 만 수행해야합니까? 이것이 @sompylasar의 테스트 가능성에 어떤 영향을 미칩니 까?

NavMenuItem을 NavMenu의 소품을 통해 필요한 모든 데이터가 전달 된 순수한 표현 구성 요소로 만들 것입니다. 이를 통해 별도로 테스트 할 수 있습니다. 따라서 두 개의 프레젠테이션 (NavMenu, NavMenuItem) 및 하나의 연결된 (connect (...) (NavMenuItem)) 구성 요소가 있습니다.

이 토론에서 내가 놓친 것은 하나의 파일에 있으면 테스트를 위해 얕은 렌더링을 사용할 수 없습니다. 사람들이이 문제를 해결하기 위해 프레젠테이션 구성 요소와 컨테이너 구성 요소를 모두 노출 한 다음 개별적으로 테스트하는 것을 보았습니다. 따라서이 경우 두 파일이 두 가지라는 것을 명시하기 위해 두 개의 파일이 필요합니다. 이것은 또한 여기서 관심사의 분리와 프리젠 테이션 구성 요소가 독립적이고 재사용 가능하다는 사실을 강조합니다.

FWIW 현재 생각을 반영하기 위해 프레젠테이션 및 컨테이너 구성 요소 문서를 업데이트했습니다.

업데이트 된 문서에서 컨테이너 구성 요소를 만드는 것을 더 이상 권장하지 않습니다.
http://redux.js.org/docs/basics/UsageWithReact.html

Redux 문서의 실제 예제에서 @gaearon 은 구성 요소가 컨테이너를 자식으로 가질 수있는 것으로 보입니다.
내가 잘못? 이것이 내부에서 똑똑한 구성 요소를 렌더링하는 멍청한 구성 요소의 테스트 가능성에 어떤 영향을 미칠 수 있습니까?
그러나 구성 요소를 계층 구조의 최신 구성 요소로 만드는 방법을 찾지 못했습니다.

Simple Data List 구성 요소 (Dumb)를 렌더링하는 앱이 있습니다.
그 안에는 모든 항목이 상점에 연결되어야하므로 스마트 한 것입니다.

문서에 따르면 괜찮지 만 문제가 생길 수 있습니까?

감사!

이것이 내부에서 똑똑한 구성 요소를 렌더링하는 멍청한 구성 요소의 테스트 가능성에 어떤 영향을 미칠 수 있습니까?

이로 인해 테스트 설정이 조금 더 어려워집니다 (스토어도 초기화해야 함). 이것이 불편한 경우 컨테이너 구성 요소를 내부로 전달할 수 있도록 children 를 허용하는 더 많은 프레젠테이션 구성 요소를 추출합니다. 일반적으로 부서는 귀하에게 달려 있으며 트레이드 오프 (작성 용이성, 리팩토링, 테스트 등)를 평가하고 구성 요소를 분리하는 방법을 직접 선택해야합니다.

좋습니다. 올바른 방법은 없습니다. 우리는 사례별로 평가해야합니다.
감사!!

Il lunedì 2016 년 2 월 8 일, Dan Abramov [email protected] ha
스크 리토 :

이것이 내부에서 렌더링되는 멍청한 구성 요소의 테스트 가능성에 어떤 영향을 미칠 수 있습니까?
똑똑한 사람?

이로 인해 테스트 설정이 조금 더 어려워집니다 (초기화해야합니다.
상점도). 불편할 때 더 추출
컨테이너를 전달할 수 있도록 자식을 허용하는 프레젠테이션 구성 요소
내부 구성 요소. 일반적으로 부서는 귀하에게 달려 있으며
트레이드 오프 (작성 용이성, 리팩토링, 테스트 등) 평가
구성 요소를 분리하는 방법을 직접 선택하십시오.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rackt/redux/issues/756#issuecomment -181143304.

루카 콜로넬로
+39345 8948718
루카. [email protected]

'레이아웃 구성 요소'는 어떻습니까? 라우터 / 내비게이터로 전달하기 위해 단일 구성 요소에 있어야하는 컨테이너가 많은 경우이 래핑 구성 요소는 '컨테이너의 멍청한 표현 컨테이너'가 될 것입니다.

@ Emilios1995 같은 문제가 있습니다 ...
레이아웃 구성 요소 내부에서 사용하는 페이지 구성 요소가 있습니다.
이 레이아웃 구성 요소에는 메뉴, 머리글, 바닥 글이 있습니다. 콘텐츠는 페이지에서 레이아웃으로 전달한 자식입니다.
메뉴와 헤더는 컨테이너입니다 !! 따라서 레이아웃은 잠재적으로 컨테이너이지만 상점에 연결되지 않습니다.

그러나 메뉴와 헤더를 레이아웃으로 전달하려고하면 레이아웃 (구성 요소)을 렌더링하고 메뉴와 헤더 (컨테이너)를 전달하는 페이지 (컨테이너)가 있습니다.

이렇게하면 계층 구조가 정확하지만 모든 페이지에서 메뉴와 헤더를 반복해야하는데, 그 비트는 모든 페이지에서 동일합니다.

@LucaColonnello 코드 없이는 문제를 이해하지 못합니다. 문제를 설명하는 간단한 예제로 StackOverflow 질문을 생성 해달라고 부탁해도 될까요? 나는 기뻐할 것입니다.

최대한 빨리

Il sabato 27 2 월 2016, Dan Abramov [email protected] ha
스크 리토 :

@LucaColonnello https://github.com/LucaColonnello 잘 모르겠습니다
코드없이 문제를 이해하십시오. 당신에게
문제를 보여주는 간단한 예제가있는 StackOverflow 질문이 있습니까? 신분증
보고 기뻐하십시오.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/reactjs/redux/issues/756#issuecomment -189672067.

루카 콜로넬로
+39345 8948718
루카. [email protected]

@gaearon 그것은 문제가 아니라 내가 여기에서 만든 질문이라고 생각합니다 : http://stackoverflow.com/questions/35729025/should-the-route-handlers-use-containers-or-presentational-components? noredirect = 1 # comment59133192_35729025

매체에 대한 Dan의 기사
https://medium.com/@dan_abramov/smart -and-dumb-components-7ca2f9a7c7d0 # .3y00gw1mq
모든 문제를 명확히합니다 ...

2016-03-01 18:19 GMT + 01 : 00 Emilio Srougo [email protected] :

@gaearon https://github.com/gaearon 문제가 아니라고 생각합니다.
오히려 내가 여기서 만든 질문 :
http://stackoverflow.com/questions/35729025/should-the-route-handlers-use-containers-or-presentational-components?noredirect=1#comment59133192_35729025

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/reactjs/redux/issues/756#issuecomment -190820426.

루카 콜로넬로
+39345 8948718
루카. [email protected]

@gaearon 프레젠테이션 구성 요소에 컨테이너 구성 요소가 포함되어있는 경우 어떻게 재사용 할 수 있습니까?
참고 :

• https://medium.com/@lars.jagare/pure -components-ftw-63e6e6c733f0 # .yw9hmwjuq
• https://medium.com/@rpominov/how -does-this-work-when-we-use-containers-inside-presentational-components-cb458e818913 # .rnxlghull

프레젠테이션 구성 요소에 컨테이너 구성 요소가 포함되어있는 경우 어떻게 재사용 할 수 있을까요?

모든 사용 시나리오에 특정 컨테이너가 포함되어 있다면 재사용 할 수없는 것이 무엇인지 알 수 없습니다. 그렇지 않은 경우 this.props.children 수락하고 특정 컨테이너 또는 프레젠테이션 구성 요소를 내부로 전달하는 다른 프레젠테이션 구성 요소를 만듭니다.

@gaearon React-Router의 [Root component] 컨테이너 컴포넌트입니까?

• route.js

<Route path="/" component={Root}>
      <IndexRoute component={Main} />
      <Route path="/account/signIn" component={SignIn} />
</Route>

• root.js

export default class Root extends React.Component {
  render() {
    return (
      <div>
        <div id="container" className="container">
          {this.props.children}
        </div>
      </div>
    );
  }

감사.

위의 @gaearon 은 디스패치에 액세스하기 위해 구성 요소를 연결하는 것을 선호한다고 말했습니다 (부모 구성 요소에서 전달하는 것과는 반대로).

이 구성 요소를 연결하고 현재 부모가 전달하는 감속기에서 매핑 할 수있는 props도 가지고 있다면 connect 에서 오도록 리팩터링 하시겠습니까? 또는 ownProps 를 사용하여 부모에게 전달되도록합니다.

두 옵션간에 기능 / 성능 차이가 있습니까?

나는 거대한 redux 프로젝트 작업 경험이 많지 않지만 react / redux 파일 구조 최적화에 대해 많은 연구와 생각을 해왔습니다. 이것이 의미가 있는지 알려주십시오.

src/
  components/
    header/ 
      navigation.js # nav menu list
      index.js # Header component
  modules/
    header/
      actions.js # header actions (sticky scroll, collapse mobile menu, etc...)
      reducer.js # header actions reducer (export to modules index)
      index.js # HeaderContainer (connect to Header component)
    index.js # combineReducers and export default configureStore (and middleware)

또 다른 개념 :

src/
  components/
    navigation.js
    logo.js
    link.js
    list.js
    item.js
  modules/
    header/
      actions.js # header actions 
      wrapper.js # header class (smart) component - to wrap header with functionality (was previously classified as container)
      container.js # header functional (dumb) component - to contain universal components
      index.js # header actions reducer - to export into modules rootReducer 

또는 구성 요소, 컨테이너 및 redux 모듈을 별도로 유지하는 것이 더 낫습니까 (동일한 이름을 공유하더라도)? 입력 해 주셔서 감사합니다.

저는 엔터프라이즈 수준의 react-redux 프로젝트로 작업 해 왔으며 제 경험을 통해 프로젝트의 아키텍처를 정의하는 방법은 전적으로 여러분에게 달려 있다고 말할 수 있습니다. React의 목적이 UI 기반의 재사용 가능한 컴포넌트를 만드는 것이라는 점에서 비실용적이기 때문에 컨테이너 / 컴포넌트 기반 아키텍처 변형을 따르지 않습니다.

그래서 저는 모듈을 기반으로 전체 프로젝트를 그룹화하는 간단한 접근 방식을 생각 해냈고 지금까지 확장 성, 유지 보수성 및 코드 가독성 측면에서 정말 잘 작동했습니다.

저에게는 컨테이너와 스마트 구성 요소가 정확히 동일합니다. 간단한 정의는 다음과 같습니다.
컨테이너 / 스마트 컴포넌트는 JSX 마크 업 + 이벤트 핸들러 + API 호출 + redux의 연결 / MSTP / MSDP를 포함하는 컴포넌트입니다.
멍청한 구성 요소는 순수하게 표현적이고 기능적인 구성 요소입니다.