Redux: connect()의 권장 사용법

나는 Brent에 강력하게 동의합니다. 이것은 Relay와 같은 것의 이면에 있는 근본적인 생각의 대부분이며 더 높은 응집력으로 이어집니다.

아마도 우리는 "사람들은 여기에 다른 선호도를 가지고 있습니다"라고 말해야 할 것입니다.

@gaearon - 트레이싱 데이터 흐름을 복잡하게 만드는 방법에 대한 데모를 포함하는

멋있는. 열어두고 초기 문서가 정리된 후 다시 살펴보겠습니다.

@gaearon 잘 봤습니다! :) 다시 방문하고 싶을 때 저에게 Ping

저는 Redux를 처음 접했지만 데이터 구조를 상당히 많이 변경한 앱을 구축하면서 지난 1년 동안 이것이 저에게 꽤 큰 골칫거리였습니다. 그래서 나는 이것 에 대해

많은 구성 요소를 연결()할 때 데이터 흐름을 추적하는 것 외에 다른 문제가 있습니까? 예를 들어 성능 저하가 있습니까?

많은 구성 요소를 연결()할 때 데이터 흐름을 추적하는 것 외에 다른 문제가 있습니까? 예를 들어 성능 저하가 있습니까?

아니요, 정반대입니다. 하향식 흐름을 포기하면 더 나은 성능을 얻을 수 있습니다.

중간 수준 구성 요소의 불필요한 다시 렌더링을 피할 수 있기 때문에?

예.

토론에 추가하려면: 저는 주로 연결 구성 요소에 대한 사용을 제한하고 있습니다. 추가 스마트 구성 요소(예: 양식 모달)를 사용할 수 있는 페이지가 있는 경우 내 해결 방법은 요소 또는 노드를 전달하고 멍청한 구성 요소가 이를 렌더링하도록 하는 것이었습니다. 그것은 당신이 좀 더 상용구를 가지고 있다는 것을 의미하지만, 멍청한 컴포넌트를 테스트하는 것은 여전히 ​​쉽습니다. 나는 여전히 이것을 실험하고 있지만 이것이 쉬운 테스트 가능성을 포기하지 않고 스마트 구성 요소를 구성하는 가장 좋은 방법일 수 있다고 생각합니다.

대략적인 예를 들자면:

푸.jsx

export class Foo extends Component {
  render () {
    return (
      <div className='foo'>
        {/* foo stuff going on in here */}
        {this.props.Bar}
      </div>
    )
  }
}

FooContainer.jsx

@connect(getState, getActions)
export class FooContainer extends Component {
  render () {
    return (
      <Foo
        Bar={<BarContainer/>}
        {...this.props}
       />
    )
  }
}

@brentvatne 무언가를 작성하고 싶다면 현재 문서 구조에서 어디에 맞출지 파악하고 자유롭게 진행하세요! :-)

2015/10/19 업데이트: 이 댓글을 개선하여 react-redux-provide 로 출시했습니다. 아래 https://github.com/rackt/redux/issues/419#issuecomment -149325401을 참조하세요.

#475에서 계속해서 내가 생각해낸 것에 대해 설명하겠습니다. 비록 이 논의가 현재 react-redux 속할 것입니다. ;)

Sideways 할당을 사용하는 모듈식 공급자

간단히 말해서, 내가 취한 접근 방식은 모든 구성 요소에 할당할 수 있는 모듈식 공급자를 중심으로 이루어집니다. 이것은 _truly_ "멍청한" 구성 요소를 허용하고, 문제의 최대 분리를 시행하며, 교환 가능한 공급자를 매우 쉽고 빠르게 사용하고 공유하는 것을 가능하게 합니다. 또한 구성 요소를 업데이트하는 보다 효율적인 방법을 시행합니다.

그래서... actions , constants , containers , reducers 및 stores 디렉토리를 제거했습니다(예제 내에서 공통 ) 단일 providers 디렉토리로 대체했습니다. 또는 providers 디렉토리가 필요하지 않을 수도 있습니다. 이 접근 방식을 사용하면 독립 실행형 공급자를 패키징하고 배포할 수 있기 때문입니다. 이 특정 접근 방식이 채택되면 정말 멋진 것들이 나올 것이라고 생각합니다!! (참고: 물론 해당 디렉토리를 하나로 통합할 필요는 없지만 1) 훨씬 더 읽기/이해하기 쉽게 만들고 2) 상용구를 줄이고 3) 개별 공급자가 충분히 작아서 의미가 있다고 생각합니다. )

"멍청한" 구성 요소의 예

// components/Branch.js

import React, { Component } from 'react';
import provide from '../utilities/provide.js';
import { branchName, tree, toggle, open, theme } from '../common/propTypes.js';
import Limbs from './Limbs.js';

<strong i="22">@provide</strong>  // maybe require specifying expected props? e.g., @provide('theme')
export default class Branch extends Component {
  static propTypes = { branchName, tree, toggle, open, theme };

  onClick(event) {
    const { branchName, toggle } = this.props;  // toggle is from a provider

    event.stopPropagation();
    toggle(branchName);
  }

  render() {
    const props = this.props;
    const { branchName, tree, open, theme } = props;  // latter 3 from providers
    const classes = theme.sheet.classes || {};
    const imgSrc = open ? 'folder-open.png' : 'folder-closed.png';

    return (
      <div
        onClick={::this.onClick}
        className={classes.branch}
      >
        <h4 className={classes.branchName}>
          <img
            className={classes.branchIcon}
            src={theme.imagesDir+imgSrc}
          />

          <span>{branchName}</span>
        </h4>

        <Limbs
          tree={tree}
          open={open}
        />
      </div>
    );
  }
}

예시 제공자

// providers/toggle.js

import createProvider from '../utilities/createProvider.js';

export const TOGGLE = 'TOGGLE';

export const actions = {
  toggle(fullPath) {
    return { type: TOGGLE, fullPath };
  }
};

export const reducers = {
  open(state = {}, action) {
    switch (action.type) {
      case TOGGLE:
        const { fullPath } = action;
        return { ...state, [fullPath]: !state[fullPath] };

      default:
        return state;
    }
  }
};

function merge (stateProps, dispatchProps, parentProps) {
  return Object.assign({}, parentProps, {
    open: !!stateProps.open[parentProps.fullPath]
  });
}

export const provider = createProvider(actions, reducers, merge);
export default provider;

옆으로 할당

언급했듯이 아이디어는 임의의 공급자를 "멍청한" 구성 요소에 쉽게 할당할 수 있다는 것입니다. 따라서 앱을 마운트할 때 다음과 같이 할 수 있습니다.

import React from 'react';
import { Provider } from 'react-redux';

import assignProviders from './utilities/assignProviders.js';
import createStoreFromProviders from './utilities/createStoreFromProviders.js';

import dark from './themes/dark.js';
import github from './sources/github.js';
import * as providers from './providers/index.js';
import * as components from './components/index.js';

const { packageList, sources, toggle, theme } = providers;
const { Branches, Branch, Limbs, Limb } = components;

const initialState = {
  packageList: [
    'github:gaearon/react-redux<strong i="10">@master</strong>',
    'github:loggur/branches<strong i="11">@master</strong>',
    'github:rackt/redux<strong i="12">@master</strong>'
  ],
  sources: {
    github: github({
      token: 'abc123',
      auth: 'oauth'
    })
  },
  open: {
    'github': true,
    'github:gaearon': true,
    'github:gaearon/react-redux<strong i="13">@master</strong>': true,
    'github:rackt': true,
    'github:rackt/redux<strong i="14">@master</strong>': true
  },
  theme: dark
};

const store = createStoreFromProviders(providers, initialState);

assignProviders({ theme }, components);
assignProviders({ packageList }, { Branches });
assignProviders({ sources }, { Branches, Branch });
assignProviders({ toggle }, { Branch, Limb });

React.render(
  <Provider store={store}>
    {() => <Branches/>}
  </Provider>,
  document.getElementById('root')
);

이 모든 것이 매우 간단하기를 바랍니다. 그러나 필요한 경우 더 자세히 설명하고 설명을 추가할 수 있어 기쁩니다.

추가 코드

이 예제에서 가져오는 유틸리티 함수가 몇 개 있음을 알 수 있습니다. 이들은 기본적으로 가장 일반적인 사용 사례를 위해 설계된 기존 redux 및 react-redux 메소드의 조합인 작은 모듈(4개 중 3개는 몇 줄 길이임)입니다. 물론 이러한 기능에 국한되지 않습니다. 그것들은 단지 일을 더 쉽게 하기 위해 존재합니다.

// utilities/createProvider.js

import { bindActionCreators } from 'redux';
import { connect } from 'react-redux';

/**
 * Creates an object to be used as a provider from a set of actions and 
 * reducers.
 *
 * <strong i="10">@param</strong> {Object} actions
 * <strong i="11">@param</strong> {Object} reducers
 * <strong i="12">@param</strong> {Function} merge Optional
 * <strong i="13">@return</strong> {Object}
 * <strong i="14">@api</strong> public
 */
export default function createProvider (actions, reducers, merge) {
  return {
    mapState(state) {
      const props = {};

      for (let key in reducers) {
        props[key] = state[key];
      }

      return props;
    },

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

    merge
  };
}

// utilities/createStoreFromProviders.js

import { createStore, combineReducers } from 'redux';

import { createStore, applyMiddleware, combineReducers } from 'redux';

/**
 * Creates a store from a set of providers.
 *
 * <strong i="17">@param</strong> {Object} providers
 * <strong i="18">@param</strong> {Object} initialState Optional
 * <strong i="19">@return</strong> {Object}
 * <strong i="20">@api</strong> public
 */
export default function createStoreFromProviders (providers, initialState) {
  const reducers = {};
  const middleware = [];
  let create = createStore;

  for (let key in providers) {
    let provider = providers[key];

    Object.assign(reducers, provider.reducers);

    if (provider.middleware) {
      if (Array.isArray(provider.middleware)) {
        for (let mid of provider.middleware) {
          if (middleware.indexOf(mid) < 0) {
            middleware.push(mid);
          }
        }
      } else if (middleware.indexOf(provider.middleware) < 0) {
        middleware.push(provider.middleware);
      }
    }
  }

  if (middleware.length) {
    create = applyMiddleware.apply(null, middleware)(createStore);
  }

  return create(combineReducers(reducers), initialState);
}

// utilities/assignProviders.js

/**
 * Assigns each provider to each component.  Expects each component to be
 * decorated with `@provide` such that it has an `addProvider` static method.
 *
 * <strong i="5">@param</strong> {Object} providers
 * <strong i="6">@param</strong> {Object} components
 * <strong i="7">@api</strong> public
 */
export default function assignProviders (providers, components) {
  for (let providerName in providers) {
    let provider = providers[providerName];

    if (provider.default) {
      provider = provider.default;
    } else if (provider.provider) {
      provider = provider.provider;
    }

    for (let componentName in components) {
      let addProvider = components[componentName].addProvider;
      if (typeof addProvider === 'function') {
        addProvider(providerName, provider);
      }
    }
  }
}

마지막으로 provide 데코레이터가 있습니다. 옆으로 할당할 수 있도록 설계된 connect 의 수정된 버전입니다.

// utilities/provide.js

import React, { Component, PropTypes } from 'react';
import createStoreShape from 'react-redux/lib/utils/createStoreShape';
import shallowEqual from 'react-redux/lib/utils/shallowEqual';
import isPlainObject from 'react-redux/lib/utils/isPlainObject';
import wrapActionCreators from 'react-redux/lib/utils/wrapActionCreators';
import invariant from 'invariant';

const storeShape = createStoreShape(PropTypes);
const defaultMapState = () => ({});
const defaultMapDispatch = dispatch => ({ dispatch });
const defaultMerge = (stateProps, dispatchProps, parentProps) => ({
  ...parentProps,
  ...stateProps,
  ...dispatchProps
});

// Helps track hot reloading.
let nextVersion = 0;

export default function provide (WrappedComponent) {
  const version = nextVersion++;
  const providers = [];
  let shouldSubscribe = false;

  function getDisplayName () {
    return ''
      +'Provide'
      +(WrappedComponent.displayName || WrappedComponent.name || 'Component')
      +'('+providers.map(provider => provider.name).join(',')+')';
  }

  function addProvider (name, { mapState, mapDispatch, merge }) {
    if (Boolean(mapState)) {
      shouldSubscribe = true; 
    }

    providers.push({
      name,
      mapState: mapState || defaultMapState,
      mapDispatch: isPlainObject(mapDispatch)
        ? wrapActionCreators(mapDispatch)
        : mapDispatch || defaultMapDispatch,
      merge: merge || defaultMerge
    });

    Provide.displayName = getDisplayName();
  }

  function computeStateProps (store) {
    const state = store.getState();
    const stateProps = {};

    for (let provider of providers) {
      let providerStateProps = provider.mapState(state);

      invariant(
        isPlainObject(providerStateProps),
        '`mapState` must return an object. Instead received %s.',
        providerStateProps
      );

      Object.assign(stateProps, providerStateProps);
    }

    return stateProps;
  }

  function computeDispatchProps (store) {
    const { dispatch } = store;
    const dispatchProps = {};

    for (let provider of providers) {
      let providerDispatchProps = provider.mapDispatch(dispatch);

      invariant(
        isPlainObject(providerDispatchProps),
        '`mapDispatch` must return an object. Instead received %s.',
        providerDispatchProps
      );

      Object.assign(dispatchProps, providerDispatchProps);
    }

    return dispatchProps;
  }

  function computeNextState (stateProps, dispatchProps, parentProps) {
    const mergedProps = {};

    for (let provider of providers) {
      let providerMergedProps = provider.merge(
        stateProps, dispatchProps, parentProps
      );

      invariant(
        isPlainObject(providerMergedProps),
        '`merge` must return an object. Instead received %s.',
        providerMergedProps
      );

      Object.assign(mergedProps, providerMergedProps);
    }

    return mergedProps;
  }

  const Provide = class extends Component {
    static displayName = getDisplayName();
    static contextTypes = { store: storeShape };
    static propTypes = { store: storeShape };
    static WrappedComponent = WrappedComponent;
    static addProvider = addProvider;

    shouldComponentUpdate(nextProps, nextState) {
      return !shallowEqual(this.state.props, nextState.props);
    }

    constructor(props, context) {
      super(props, context);
      this.version = version;
      this.store = props.store || context.store;

      invariant(this.store,
        `Could not find "store" in either the context or ` +
        `props of "${this.constructor.displayName}". ` +
        `Either wrap the root component in a <Provider>, ` +
        `or explicitly pass "store" as a prop to "${this.constructor.displayName}".`
      );

      this.stateProps = computeStateProps(this.store);
      this.dispatchProps = computeDispatchProps(this.store);
      this.state = { props: this.computeNextState() };
    }

    recomputeStateProps() {
      const nextStateProps = computeStateProps(this.store);
      if (shallowEqual(nextStateProps, this.stateProps)) {
        return false;
      }

      this.stateProps = nextStateProps;
      return true;
    }

    recomputeDispatchProps() {
      const nextDispatchProps = computeDispatchProps(this.store);
      if (shallowEqual(nextDispatchProps, this.dispatchProps)) {
        return false;
      }

      this.dispatchProps = nextDispatchProps;
      return true;
    }

    computeNextState(props = this.props) {
      return computeNextState(
        this.stateProps,
        this.dispatchProps,
        props
      );
    }

    recomputeState(props = this.props) {
      const nextState = this.computeNextState(props);
      if (!shallowEqual(nextState, this.state.props)) {
        this.setState({ props: nextState });
      }
    }

    isSubscribed() {
      return typeof this.unsubscribe === 'function';
    }

    trySubscribe() {
      if (shouldSubscribe && !this.unsubscribe) {
        this.unsubscribe = this.store.subscribe(::this.handleChange);
        this.handleChange();
      }
    }

    tryUnsubscribe() {
      if (this.unsubscribe) {
        this.unsubscribe();
        this.unsubscribe = null;
      }
    }

    componentDidMount() {
      this.trySubscribe();
    }

    componentWillReceiveProps(nextProps) {
      if (!shallowEqual(nextProps, this.props)) {
        this.recomputeState(nextProps);
      }
    }

    componentWillUnmount() {
      this.tryUnsubscribe();
    }

    handleChange() {
      if (this.recomputeStateProps()) {
        this.recomputeState();
      }
    }

    getWrappedInstance() {
      return this.refs.wrappedInstance;
    }

    render() {
      return (
        <WrappedComponent ref='wrappedInstance' {...this.state.props} />
      );
    }
  }

  if ((
    // Node-like CommonJS environments (Browserify, Webpack)
    typeof process !== 'undefined' &&
    typeof process.env !== 'undefined' &&
    process.env.NODE_ENV !== 'production'
   ) ||
    // React Native
    typeof __DEV__ !== 'undefined' &&
    __DEV__ //eslint-disable-line no-undef
  ) {
    Provide.prototype.componentWillUpdate = function componentWillUpdate () {
      if (this.version === version) {
        return;
      }

      // We are hot reloading!
      this.version = version;

      // Update the state and bindings.
      this.trySubscribe();
      this.recomputeStateProps();
      this.recomputeDispatchProps();
      this.recomputeState();
    };
  }

  return Provide;
}

provide 데코레이터에 대해 언급할 가치가 있는 한 가지는 react-devtools 사용하여 모든 것을 보면 다음과 같은 것을 볼 수 있다는 것입니다( Branches 는 ProvideBranches(theme,packageList,sources) ):

이 대신( Branches 가 Connect(Branches) 래핑되는 원래 connect 에서 볼 수 있음):

제한 사항

이틀 전에 redux 에 대해 배우기 시작했기 때문에 솔직히 이 접근 방식의 결과로 어떤 제한(있는 경우)이 있는지 전혀 모릅니다. 내 머리 꼭대기에서, 나는 정말로 아무 것도 생각할 수 없으며 모든 것이 내 사용 사례에 완벽하게 작동하는 것처럼 보이지만 아마도 더 경험이 많은 사람이 알릴 수 있습니다.

이 특정 접근 방식을 생각해 낸 이유는 할당된 공급자를 가질 수 있는 _정말_ "멍청한" 구성 요소가 있다는 아이디어가 마음에 들기 때문입니다. 이는 관심사의 진정한 분리를 시행하고 모듈로 쉽게 교환할 수 있는 제공자를 원하는 수만큼 허용합니다.

또한 @gaearon 이 이 접근 방식을 좋아하고 react-redux 범위에 해당한다고 생각하면 추가된 PR을 제출하게 되어 기쁩니다. 그렇지 않은 경우 react-redux-providers 를 만들고 게시한 다음 결국에는 실제 사례와 함께 예제 공급자(예: react-redux-provide-toggle )를 게시할 것입니다.

중간 수준 구성 요소의 불필요한 다시 렌더링을 피할 수 있기 때문에?

예

지금 취한 방향은 상태에 Immutable.js를 사용하고(앱 상태와 UI 상태 모두, 일부 UI 상태는 구성 요소에 유지) 모든 구성 요소에 PureRenderMixin을 사용한다는 것입니다. 이것은 하향식 흐름을 사용할 때의 성능 저하를 제거하지 않습니까?

편집: 낮은 수준의 구성 요소 중 하나가 여전히 다시 렌더링해야 하는 경우 중간 수준 구성 요소에 대한 성능 저하를 제거하지 못하지만 여전히 많은 오버헤드를 제거해야 한다는 것을 깨달았습니다. 어떤 경험이 있습니까?

@danmaz74 우리는 이와 같은 시나리오에서 성능 문제를

@eldh 업데이트에 감사드립니다. 의미가 있습니다. 진행하는 동안 참고하겠습니다. :)

이에 대한 업데이트가 있습니까? timbur의 예는 나에게 완벽하게 이해되지만 단일 연결 연습은 잘 이해하지 못합니다. 나는 반대 논증, 즉 "사람들은 여기에서 선호하는 차이가 있습니다"에 관심이 있습니다.

단일 연결을 사용하면 상태를 10개의 구성 요소 깊은 계층 구조로 완전히 변환하기 위해 거대한 mapStateToProps 함수가 필요합니다... 그 이면의 생각이 무엇인지 또는 내가 뭔가를 오해하고 있는지 약간 혼란스럽습니다...

단일 연결을 사용하면 거대한 mapStateToProps 함수가 필요합니다.

아무도 단일 연결을 옹호하지 않습니다.

그런 다음 react-redux의 connect() 함수를 사용하여 Redux에 연결하려는 구성 요소를 래핑합니다. 최상위 구성 요소 또는 경로 처리기 에 대해서만 이 작업을 수행하십시오. 기술적으로 앱의 모든 구성 요소를 Redux 스토어에 연결할 수 있지만 너무 깊게 연결 하면 데이터 흐름을 추적하기가 더 어려워지므로

"단일"은 예제에서 만든 것과 같은 작은 앱만 나타냅니다. 이것을 더 명확히 하기 위해 자유롭게 문서를 수정하십시오. 나는 지금 다른 프로젝트로 바쁘므로 누군가가 PR을 하지 않는 한 이 문제가 어떤 움직임도 기대하지 마십시오. 당신도 할 수 있습니다.

명확하게 해 주셔서 감사합니다.

마침내 react-redux-provide 출시에 이르렀습니다. 여기에서 확인

아주 좋아 보입니다. 감사합니다!

저는 새로운 redux 프로젝트를 막 시작했고 '스마트' 구성 요소에 연결을 사용하고 있습니다. 이것은 나에게 훨씬 더 이해가 되며 성능상의 이점이 있다면 추가 승리가 있습니다. 반대로, 모든 제어를 기본 앱이나 라우터까지 버블링하면 SRP가 완전히 손실됩니다. 문제를 분해하기 시작하기 전에 앱이 얼마나 커야 할까요?

관련 요소를 구성 요소 폴더로 구성하는 방법도 생각하고 있습니다. 주성분 옆에 감속기를 두십시오.

궁극적으로 나는 redux/flux가 예측 가능한 상태에 대한 큰 이점이라고 믿습니다. 그러나 표준 mv에서 그러한 정신적 변화-UI 앱 개발을 간단하고 누구나 액세스할 수 있게 만든 것이 무엇이든 간에, 결국에는 그 플럭스가 추상화되고 우리는 이동할 것입니다. mv*와 더 비슷하게 보이는 것으로 돌아갑니다.

이것은 #1285에서 수정되고 있습니다.

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

안녕하세요, 여기에 도움이 될 만한 몇 가지 항목에 대해 썼습니다. :)

https://medium.com/@timbur/react -automatic-redux-providers-and-replicators-c4e35a39f1

https://github.com/reactjs/redux/issues/419#issuecomment -183769392도 #1353에 도움이 될 수 있다고 생각합니다.

@timbur 멋진 기사! 이 질문에 대한 생각을 공유해 주시겠습니까? https://github.com/reactjs/react-redux/issues/278

이것이 눈에 띄게 분명한지 확실하지 않지만 명확성을 위해 여기에 추가할 가치가 있다고 생각합니다. 언급된 많은 내용이 이 스레드에 오는 redux를 처음 접하는 사람에게는 다소 추상적일 수 있다고 생각하기 때문입니다.

내가 처음 redux를 사용하기 시작했을 때 내 앱이 많은 분리를 필요로 하지 않을 것이라고 생각했기 때문에 (그냥 평범한 오래된 멍청한) "구성 요소" 안에 "컨테이너"(연결된 구성 요소)를 잘못 점으로 표시했습니다. 내가 얼마나 틀렸어. 이러한 구성 요소 중 많은 부분을 재사용해야 한다는 것을 깨달았을 때 상당한 양의 리팩토링을 수행해야 했고 많은 스마트 항목을 트리 맨 위로 옮겼지만 곧 다루기 어려워졌습니다. 컨텍스트를 제공하는 상단의 "제공자"(필요한 대로)뿐 아니라 기본적으로 모든 앱(하지 않아야 함)도 제공합니다.

내가 접근하는 가장 좋은 방법은 맨 위에 공급자가 있는 벙어리 구성 요소를 구성하는 컨테이너 계층 구조를 갖는 것입니다. 컨테이너는 다른 컨테이너 내부에만 있어야 합니다 . 앱은 구성 요소를 사용하여 데이터를 표시하는 컨테이너의 계층 구조여야 합니다.

종종 목록을 사용하여 이 작업을 수행하는 좋은 방법은 스마트 구성 요소를 통해 ID를 전달하는 것입니다. ID가 필요하다는 것은 무언가가 앱의 도메인에 속한다는 표시입니다. 따라서 가능한 경우 한 컨테이너에 있는 ID 목록을 가져와서 ID를 사용하여 원하는 정보를 얻을 수 있는 다른 컨테이너로 전달합니다. 각 컨테이너 내에서 구성 요소를 사용하여 ID 없이도 해당 정보를 렌더링합니다.

아래에서 구성 요소를 사용하여 표시하는 컨테이너 계층을 통해 앱의 연결된 부분을 전달하는 방법의 (복잡한) 예제를 조롱했습니다.

// Provider component that renders some containers and some components and provides the store
class TodoAppProvider {
  constructor() {
    // setup store etc.
  }

  render() {
    return (
      <Provider store={this.store}> {/* Provider from 'react-redux' */}
        <AppLayoutComponent title="My Todos" footer={<TodoFooter />}>
          <TodoListsContainer />
        </AppLayoutComponent>
      </Provider>
    );
  }
);

// AppLayoutComponent
// Lots of nice css, other dumb components etc. no containers!
export default const AppLayoutComponent = ({ title, children, footer }) => (
  <header>
    {title}
  </header>
  <main>
    {children /* This variable can be a container or components but it's not hardcoded! */}
  </main>
  <footer>
    {footer}
  </footer>
);

// TodoFooter
// Another dumb component
export default const TodoFooter = () => (
  <footer>
    &copy; {Date.now() /* we are copyrighted to the millisecond */}
  </footer>
);

// TodoListsContainer
// Smart component that renders all the lists
class TodoListsContainer extends React.Component {
  render() {
    return () {
      <div>
        {todoLists.map(id => (
          {/* this container renders another container */ }
          <TodoListContainer key={id} todoListId={id} />
        ))}
      </div>
    }
  }
}

const mapStateToProps = state => ({
  todoLists: getTodoLists(state),
});

export default connect(mapStateToProps)(TodoListsContainer);

// TodoListContainer
// Gets the props and visibleTodo IDs for the list
class TodoListContainer {
  render() {
    const { id, title, visibleTodos } = this.props;
    return (
      <div>
        {/* Render a component but passes any connected data in as props / children */}
        <TodoListPanelComponent title={title}>
          {visibleTodos.map(id => (
            <TodoContainer todoId={id} />
          ))}
        </TodoListPanelComponent>
      </div>
    );
  }
}

const mapStateToProps = (state, { todoListId }) => ({
  ...getTodoList(state, todoListId), // A todo object (assume we need all the attributes)
  visibleTodos: getVisibleTodos(state, todoListId), // returns ids
});

export default connect(mapStateToProps)(TodoListContainer);


// TodoListPanelComponent
// render the panel to sit the todos in
// children should be todos
// No containers!
export default const TodoListPanelComponent = ({ title, children }) => (
  <div>
    <h3>{title}</h3>
    <div>
      {children}
    </div>
  </div>
);

// TodoContainer
// This just wraps the TodoComponent and passed the props
// No separate class or JSX required!
const mapStateToProps = (state, { todoId }) => ({
  ...getTodo(state, todoId),
});

const mapDispatchToProps = (dispatch, { todoListId }) => ({
  handleFilter: () => dispatch(hideTodo(id)), // Pass ALL smart stuff in
});

export default connect(mapStateToProps, mapDispatchToProps)(TodoComponent); // Passing in the component to connect

// TodoComponent
// Render the component nicely; again, as all of its connected stuff passed in
// The FilterLinkContainer is an example of a smell that will come back to bite you!
export default const TodoComponent = ({ content, isComplete, handleFilter }) => (
  <div>
    <div>
      {content}
    </div>
    <div>
      {isComplete ? '✓' : '✗'}
    </div>
    <div>
      {/* Don't do this, can't re-use TodoComponent outside the app context! */}
      <FilterLinkContainer />

      {/* Instead do this (or similar), component can be reused! */}
      <Link onClick={handleFilter}>
        'Filter'
      </Link>
    </div>
  </div>
);

따라서 여기서 컨테이너 계층 구조는 TodoAppProvider > TodoListsContainer > TodoListContainer > TodoContainer 입니다. 그것들은 각각 서로에 의해 렌더링되고 구성 요소 내부에서 렌더링되지 않으며 원시 보기 코드를 포함하지 않습니다(React 래핑 이유로 가끔 div 제외).

궁극적으로 내가 생각하는 방식은 마치 처음에 UI가 관심을 갖는 유용한 방식으로 데이터를 매핑하는 연결된 구성 요소의 트리를 만드는 것과 같습니다. 그러나 UI는 전혀 없으며 컨테이너의 계층 구조를 통해 매핑된 상태 트리 만 있습니다. 그 후, 원하는 방식으로(즉, DOM에서) 실제로 데이터를 표시하기 위해 해당 컨테이너 내부에 프리젠테이션 구성 요소를 살펴보고 뿌립니다. 분명히 이 2단계 방식으로 앱을 작성하는 것은 유용하지 않지만 이와 같은 모델을 개념화하는 것이 유용하다는 것을 알았습니다.

connect() 두 번 이상 사용하면 성능 저하(또는 다른 아키텍처상의 이유)가 있습니까? 다음과 같은 방식으로 연결 진입점을 추상화하여 구성 요소에 자주 사용되는 소품을 제공하려고 합니다.

// connectCommonProps.js (mergeProps not included for the sake of simplicity)

const _mapStateToProps = (state) => ({ [often used slices of state] });

const _mapDispatchToProps = (dispatch) => ({ [often used actions] });

const connectCommonProps = (mapStateToProps, mapDispatchToProps, component) => {
    // First connect
    const connectedComponent = connect(mapStateToProps, mapDispatchToProps)(component);

    // Second connect
    return connect(_mapStateToProps, _mapDispatchToProps)(connectedComponent);
};

export default connectMapAndFieldProps;

// Some component that needs the often used props
...
export default connectCommonProps(..., ..., Component);

나는 여기에서 게으르고 선언을 단순하게 유지하기 때문에 mapStateToProps 의 두 가지 버전과 mapDispatchToProps 의 두 가지 버전을 결합하지 않았습니다. 하지만 connect 가 나를 위해 일하게 하는 것이 나쁜 생각인지 궁금합니다.

@timotgl : Dan은 더 이상 활성 유지 관리자가 아닙니다. Dan에게 직접 ping을 보내지 마십시오.

여러 구성 요소 연결 에

개인적으로 다른 접근 방식을 시도하는 것이 좋습니다. "공통 props" HOC 또는 대부분 자식에게 전달하는 무언가가 있거나 선택기를 사용하여 특정 구성 요소의 mapState 함수에서 공통 props를 검색하고 필요한 특정 props와 결합합니다.

@markerikson 죄송합니다 몰랐습니다 멘션이 삭제되었습니다.

따라서 우선 작동하고 구성 요소는 반응 개발 도구의 다른 연결된 구성 요소처럼 나타나며 추가 래퍼 또는 이와 유사한 것이 없습니다.

나는 OOP/상속 패러다임을 포함하고 싶지 않았기 때문에 HOC에 반대하기로 결정했습니다. 구성 요소에 더 많은 소품을 제공하는 것일 뿐이므로 동작은 그대로 유지됩니다.

mapStateToProps 에서 배선하는 것에 대한 좋은 점입니다. 그것은 작동하지만 적어도 2개의 진입점이 있습니다. 연결하기 위해 하나의 도우미 함수를 호출하는 것이 더 간단해 보입니다.

"2개의 진입점"이 무엇을 의미하는지 잘 모르겠습니다.

내가 그리는 것은 다음과 같습니다.

import {selectCommonProps} from "app/commonSelectors";

import {selectA, selectB} from "./specificSelectors";

const mapState = (state) => {
    const propA = selectA(state);
    const propB = selectB(state);
    const commonProps = selectCommonProps(state);

    return {a, b, ...commonProps};
}

@markerikson 두 개의 진입점으로 mapDispatchToProps 대해 동일한 작업을 수행해야 하고 잠재적으로 mergeProps 대해서도 마찬가지입니다.

mergeProps 는 거의 사용하지 않아야 합니다. 이는 최후의 수단으로 탈출구로 사용하는 것이므로 사용을 권장하지 않습니다. 또한 일반적으로 실제 mapDispatch 함수를 실제로 작성하지 않고 대신 "객체 속기"를 사용하는 것이 좋습니다.

import {addTodo, toggleTodo} from "./todoActions";

class TodoList extends Component {}

const actions = {addTodo, toggleTodo};
export default connect(mapState, actions)(TodoList);

모든 "공통" 작업 작성자를 다시 내보내고 다음과 같은 작업을 수행하는 일부 index.js 파일을 쉽게 가질 수 있습니다.

import * as commonActions from "app/common/commonActions";
import {specificAction1, specificAction2} from "./actions";

const actionCreators = {specificAction1, specificAction2, ...commonActions};

export default connect(null, actionCreators)(MyComponent);

mergeProps 는 거의 사용하지 않아야 합니다. 이는 최후의 수단으로 탈출구로 사용하는 것이므로 사용을 권장하지 않습니다.

@markerikson님 안녕하세요, 누군가 mergeProps 사용을 피해야 하는 이유가 궁금합니다. mapDispatchToProps의 내 작업에 필요할 수 있지만 구성 요소가 아닌 mapStateToProps에서 소품을 "숨기기"하는 것이 매우 편리합니다. 나쁜 일입니까?