Redux: कनेक्ट का अनुशंसित उपयोग ()

मैं ब्रेंट से दृढ़ता से सहमत हूं। यह रिले जैसी किसी चीज़ के पीछे की मूलभूत सोच थी और उच्च सामंजस्य की ओर ले जाती है।

शायद हमें सिर्फ यह कहना चाहिए कि "यहां लोगों की अलग प्राथमिकताएं हैं"।

@gaearon - शायद ट्रेडऑफ़ पर एक खंड जिसमें यह प्रदर्शित होता है कि यह डेटा प्रवाह को कैसे जटिल करता है, यह उपयोगी होगा। मैं उसके लिए वरीयताओं के अपने पक्ष में पिच कर सकता था।

ठंडा। आइए इसे खुला रखें और प्रारंभिक दस्तावेज़ों के व्यवस्थित होने के बाद फिर से देखें।

अच्छा लगता है @gaearon! :) मुझे पिंग करें जब आप फिर से आना चाहेंगे

मैं Redux के लिए काफी नया हूं, लेकिन पिछले साल के दौरान यह मेरे लिए एक बहुत बड़ा दर्द बिंदु रहा है, एक ऐप बनाना जहां हमने डेटा संरचना को काफी बदल दिया है। तो कहना होगा कि मैं वास्तव में इस पर @brentvatne से सहमत हूं।

क्या बहुत सारे घटकों को जोड़ने () के दौरान डेटा प्रवाह का पता लगाने के अलावा अन्य समस्याएं हैं? उदाहरण के लिए प्रदर्शन जुर्माना होगा?

क्या बहुत सारे घटकों को जोड़ने () के दौरान डेटा प्रवाह का पता लगाने के अलावा अन्य समस्याएं हैं? उदाहरण के लिए प्रदर्शन जुर्माना होगा?

नहीं, यह बिल्कुल विपरीत है: आप टॉप-डाउन प्रवाह को छोड़ कर बेहतर प्रदर्शन प्राप्त करते हैं।

क्योंकि आप मध्य-स्तर के घटकों के अनावश्यक पुन: प्रस्तुतीकरण से बच सकते हैं?

हां।

चर्चा में जोड़ने के लिए: मैं ज्यादातर रूट घटकों से कनेक्ट करने के अपने उपयोग को सीमित कर रहा हूं। जब मेरे पास एक पृष्ठ होता है जो एक अतिरिक्त स्मार्ट घटक (उदाहरण के लिए एक फॉर्म मोडल) का उपयोग कर सकता है, तो मेरा कामकाज तत्व या नोड को पास करना है, और गूंगा घटक इसे प्रस्तुत करना है। इसका मतलब है कि आपके पास थोड़ा अधिक बॉयलरप्लेट है, लेकिन गूंगा घटक का परीक्षण करना अभी भी आसान है। मैं अभी भी इसके साथ प्रयोग कर रहा हूं, लेकिन मुझे लगता है कि आसान टेस्टेबिलिटी को छोड़े बिना स्मार्ट घटकों को लिखने के बारे में जाने का यह सबसे अच्छा तरीका हो सकता है।

एक मोटा उदाहरण देने के लिए:

फू.जेएसएक्स

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 । ;)

बग़ल में असाइनमेंट का उपयोग कर मॉड्यूलर प्रदाता

लंबी कहानी संक्षेप में, मैंने जो दृष्टिकोण अपनाया है वह मॉड्यूलर प्रदाताओं के इर्द-गिर्द घूमता है जिन्हें आप किसी भी घटक को सौंप सकते हैं। यह _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')
);

उम्मीद है कि यह सब बहुत सीधा है, लेकिन मुझे और अधिक विस्तार में जाने और यदि आवश्यक हो तो स्पष्टीकरण के लिए टिप्पणियां जोड़ने में खुशी होगी।

अतिरिक्त कोड

आप शायद इन उदाहरणों में कुछ मुट्ठी भर उपयोगिता कार्यों को आयात करते हुए देखेंगे। ये छोटे मॉड्यूल हैं (चार में से 3 केवल कुछ पंक्तियां लंबी हैं) जो मूल रूप से मौजूदा redux और react-redux विधियों का एक संयोजन हैं, जिन्हें सबसे आम उपयोग-मामलों के लिए डिज़ाइन किया गया है। आप निश्चित रूप से इन कार्यों तक ही सीमित नहीं हैं। वे केवल चीजों को और भी आसान बनाने के लिए मौजूद हैं।

// 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) में लपेटा जाता है

इसके बजाय (जिसे आप मूल connect साथ देखेंगे, जहां Branches Connect(Branches) साथ लपेटा जाता है):

सीमाओं

मैंने केवल दो दिन पहले redux बारे में सीखना शुरू किया था, इसलिए मुझे ईमानदारी से पता नहीं है कि इस दृष्टिकोण के परिणामस्वरूप क्या (यदि कोई हो) सीमाएं मौजूद हैं। मेरे सिर के ऊपर से, मैं वास्तव में किसी के बारे में नहीं सोच सकता, और मेरे उपयोग के मामलों के लिए सब कुछ पूरी तरह से काम करता प्रतीत होता है, लेकिन शायद कोई और अनुभवी इसमें शामिल हो सकता है।

मैं इस विशेष दृष्टिकोण के साथ आया क्योंकि मुझे वास्तव में _truly_ "गूंगा" घटक होने का विचार पसंद है, जो किसी भी प्रदाता को उन्हें सौंपा जा सकता है। यह चिंताओं के एक सच्चे अलगाव को लागू करता है, और यह मॉड्यूल के रूप में आसानी से विनिमेय प्रदाताओं की किसी भी संख्या की अनुमति देता है।

इसके अलावा, अगर @gaearon इस दृष्टिकोण को पसंद करता है और सोचता है कि यह react-redux के दायरे में आता है, तो मुझे अतिरिक्त के साथ एक पीआर सबमिट करने में खुशी होगी। यदि नहीं, तो शायद मैं react-redux-providers बनाऊंगा और प्रकाशित करूंगा, और फिर अंततः कुछ वास्तविक दुनिया के उदाहरणों के साथ उदाहरण प्रदाताओं (उदाहरण के लिए, react-redux-provide-toggle जैसी सामग्री) प्रकाशित करूंगा।

क्योंकि आप मध्य-स्तर के घटकों के अनावश्यक पुन: प्रस्तुतीकरण से बच सकते हैं?

हां

अब हमने जो दिशा ली है, वह यह है कि हम अपने राज्य के लिए Immutable.js का उपयोग करने जा रहे हैं (ऐप स्टेट और UI स्टेट दोनों; हम घटकों में कुछ UI स्टेट रखते हैं), और फिर अपने सभी घटकों के लिए PureRenderMixin का उपयोग करें। क्या यह टॉप-डाउन प्रवाह का उपयोग करने के प्रदर्शन दंड को समाप्त नहीं करेगा?

संपादित करें: मुझे अभी एहसास हुआ है कि यह मध्य-स्तर के घटकों के लिए उस प्रदर्शन दंड को समाप्त नहीं करेगा यदि उनके निचले स्तर के घटकों में से एक को अभी भी फिर से प्रस्तुत करने की आवश्यकता है, लेकिन इसे अभी भी बहुत अधिक ओवरहेड को खत्म करना चाहिए। इसके साथ कोई अनुभव?

@ danmaz74 हम इस तरह के परिदृश्यों में perf मुद्दों को मार रहे हैं (redux का उपयोग नहीं कर रहे हैं, लेकिन एक बहुत ही समान घर में बने lib)। हालांकि, हमारे पास कुछ बहुत ही "महंगे" घटकों के साथ एक बहुत ही जटिल ऐप है। साथ ही, जैसे-जैसे ऐप बड़ा होता जाता है, केवल शीर्ष स्तर की तुलना में अधिक स्थानों में डेटा इंजेक्ट करने से आपको घटकों के बीच निहित निर्भरता बनाने से बचने में मदद मिल सकती है और माता-पिता को अपने बच्चों की डेटा आवश्यकताओं के बारे में बहुत अधिक जानकारी होने से बचने में मदद मिल सकती है।

@eldh अद्यतन के लिए धन्यवाद, यह समझ में आता है। आगे बढ़ते समय हम इसे ध्यान में रखेंगे :)

इस पर कोई अपडेट? टिम्बूर का उदाहरण मेरे लिए एकदम सही है, जबकि एकल कनेक्ट अभ्यास मुझे बिल्कुल समझ में नहीं आता है। मुझे काउंटर तर्क में दिलचस्पी होगी, यानी "लोगों की यहां अंतर प्राथमिकताएं हैं"।

एक एकल कनेक्ट का उपयोग करने के लिए राज्य को सभी तरह से बदलने के लिए एक विशाल mapStateToProps फ़ंक्शन की आवश्यकता होगी जैसे कि 10 घटक गहरे पदानुक्रम ... मैं थोड़ा उलझन में हूं कि इसके पीछे क्या विचार है या क्या मैं कुछ गलत समझ रहा हूं ...

एकल कनेक्ट का उपयोग करने के लिए एक विशाल mapStateToProps फ़ंक्शन की आवश्यकता होगी

कोई भी एकल कनेक्ट की वकालत नहीं करता है।

फिर, हम रिएक्ट-रेडक्स से कनेक्ट () फ़ंक्शन के साथ उन घटकों को लपेटते हैं जिन्हें हम Redux से कनेक्ट करना चाहते हैं। इसे केवल शीर्ष-स्तरीय घटक, या रूट हैंडलर के लिए करने का प्रयास करें। जबकि तकनीकी रूप से आप अपने ऐप के किसी भी घटक को Redux स्टोर से कनेक्ट () कर सकते हैं,

"एकल" केवल छोटे ऐप्स को संदर्भित करता है जैसे कि हम उदाहरण में बनाते हैं। कृपया इसे बेहतर ढंग से स्पष्ट करने के लिए दस्तावेज़ों में संशोधन करने के लिए स्वतंत्र महसूस करें। मैं अब अन्य परियोजनाओं में व्यस्त हूं, इसलिए कृपया इस मुद्दे पर कोई हलचल होने की उम्मीद न करें जब तक कि कोई पीआर नहीं करता। तुम से भी हो सकता है।

स्पष्टीकरण के लिए धन्यवाद।

अंत में react-redux-provide जारी करने के लिए तैयार हो गया। इसे यहां देखें । मैं अगले कुछ दिनों/सप्ताहों में कुछ अन्य सामग्री भी जारी करूँगा।

यह बहुत अच्छा लग रहा है, धन्यवाद!

मैंने अभी एक नया रेडक्स प्रोजेक्ट शुरू किया है, और 'स्मार्ट' घटकों के लिए कनेक्ट का उपयोग कर रहा हूं - यह मेरे लिए कहीं अधिक समझ में आता है, और यदि कोई पूर्ण लाभ है तो अतिरिक्त जीत है। इसके विपरीत, यदि आपने मुख्य ऐप या राउटर तक सभी नियंत्रण बबल कर दिए हैं, तो एसआरपी का पूर्ण नुकसान होता है - चीजों को तोड़ने से पहले आपके ऐप को कितना बड़ा होना चाहिए?

मैं संबंधित तत्वों को घटक फ़ोल्डर में व्यवस्थित करने के बारे में भी सोच रहा हूं - यानी। इसके मुख्य घटक आदि के बगल में एक रेड्यूसर लगाएं।

अंततः, मेरा मानना ​​है कि रेडक्स/फ्लक्स पूर्वानुमानित अवस्था के लिए एक बहुत बड़ा लाभ है, लेकिन मानक एमवी से इस तरह की मानसिक बदलाव-जो कुछ भी यूआई ऐप के विकास को सरल और किसी के लिए भी सुलभ बनाता है, अंततः प्रवाह को दूर कर दिया जाएगा और हम आगे बढ़ेंगे किसी ऐसी चीज़ पर वापस जाएँ जो 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

मुझे यकीन नहीं है कि यह स्पष्ट रूप से स्पष्ट है, लेकिन मुझे लगता है कि इसे स्पष्टता के लिए यहां जोड़ने लायक है, क्योंकि मुझे लगता है कि जो कुछ कहा गया है वह शायद इस धागे में आने वाले किसी नए व्यक्ति के लिए थोड़ा सा सार है।

जब मैंने पहली बार रेडक्स का उपयोग करना शुरू किया तो मैंने "कंटेनरों" (जुड़े घटकों) को गुमराह किया (केवल सादा पुराना गूंगा) "घटक" क्योंकि मुझे लगा कि मेरे ऐप को ज्यादा डिकूपिंग की आवश्यकता नहीं है। मैं कितना गलत था। जब मुझे एहसास हुआ कि मुझे इनमें से कई घटकों का पुन: उपयोग करने की आवश्यकता है, तो मुझे काफी हद तक रिफैक्टरिंग करनी होगी और बहुत सारे स्मार्ट सामान को पेड़ के शीर्ष पर ले जाना होगा, लेकिन यह जल्द ही बोझिल हो गया; शीर्ष पर एक "प्रदाता" संदर्भ प्रदान करता है (जैसा कि इसे करना चाहिए) लेकिन मूल रूप से सभी ऐप (जो इसे नहीं करना चाहिए)।

जिस तरह से मैंने इसे प्राप्त करने के लिए सबसे अच्छा पाया है, शीर्ष पर एक प्रदाता के साथ, गूंगा घटकों की रचना करने वाले कंटेनरों का पदानुक्रम होना है। कंटेनरों को केवल अन्य कंटेनरों के अंदर रहना चाहिए . आपका ऐप कंटेनरों का एक पदानुक्रम होना चाहिए जो अपने डेटा को प्रस्तुत करने के लिए घटकों का उपयोग करते हैं।

सूचियों के साथ ऐसा करने का अक्सर एक अच्छा तरीका स्मार्ट घटकों के माध्यम से आईडी को पास करना है। एक आईडी की आवश्यकता एक संकेत है कि कुछ ऐप के डोमेन से संबंधित है। इसलिए जहां संभव हो एक कंटेनर में आईडी की सूचियां लें और उन्हें दूसरे कंटेनर में भेज दें, जो आईडी का उपयोग अपनी इच्छित जानकारी प्राप्त करने के लिए कर सकता है। आईडी की आवश्यकता के बिना उस जानकारी को प्रस्तुत करने के लिए प्रत्येक कंटेनर के भीतर एक घटक का उपयोग करें।

नीचे मैंने एक कंटेनर पदानुक्रम के माध्यम से ऐप के कनेक्टेड हिस्सों को पास करने के तरीके के बारे में एक (जटिल) उदाहरण का मज़ाक उड़ाया है जो उन्हें प्रदर्शित करने के लिए घटकों का उपयोग करता है।

// 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 । वे प्रत्येक एक दूसरे द्वारा प्रदान किए जाते हैं, कभी भी एक घटक के अंदर प्रस्तुत नहीं किए जाते हैं, और इसमें कोई कच्चा दृश्य कोड नहीं होता है (रिएक्ट रैपिंग कारणों के लिए सामयिक div के अलावा)।

अंतत:, जिस तरह से मैं इसके बारे में सोचना पसंद करता हूं, वह यह है कि आप शुरू में कनेक्टेड घटकों का एक पेड़ बनाना चाहते थे जो आपके डेटा को एक उपयोगी तरीके से मैप करता है जिससे आपका UI _will_ परवाह करता है। हालांकि, कोई यूआई नहीं है, केवल कंटेनरों के पदानुक्रम के माध्यम से मैप किए गए राज्य का एक पेड़ है। उसके बाद, आप उन कंटेनरों के अंदर प्रस्तुतिकरण घटकों के माध्यम से जाते हैं और वास्तव में डेटा को किसी भी तरह से प्रदर्शित करने के लिए छिड़कते हैं (यानी डीओएम में)। जाहिर है कि आपके ऐप को इस टू-पास तरीके से लिखना उपयोगी नहीं है, लेकिन मुझे इस तरह के मॉडल की अवधारणा करना उपयोगी लगा।

क्या एक से अधिक बार 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 : डैन अब सक्रिय अनुरक्षक नहीं है - कृपया उसे सीधे पिंग न करें।

मैं यह कहने वाला था कि आपके प्रश्न का उत्तर Redux FAQ प्रविष्टि में कई घटकों को जोड़ने पर दिया गया है , लेकिन ऐसा लगता है कि आप कुछ अलग के बारे में पूछ रहे हैं - जानबूझकर एक ही घटक के आसपास कई कनेक्शन लपेट रहे हैं? मैं यह नहीं कह सकता कि मैंने पहले कभी किसी को ऐसा करते देखा है, और मैंने Redux कोड का _lot_ देखा है।

व्यक्तिगत रूप से, मैं एक अलग दृष्टिकोण की कोशिश करने का सुझाव दूंगा। या तो एक "कॉमन प्रॉप्स" एचओसी या ऐसा कुछ है जो ज्यादातर अपने बच्चों के माध्यम से पास करता है, या विशिष्ट घटक के mapState फ़ंक्शन में सामान्य प्रॉप्स को पुनः प्राप्त करने के लिए चयनकर्ताओं का उपयोग करता है और उन्हें आवश्यक विशिष्ट प्रॉप्स के साथ संयोजित करता है।

@markerikson क्षमा करें, यह नहीं पता था, उल्लेख हटा दिया गया है।

तो सबसे पहले, यह काम करता है, और घटक प्रतिक्रिया देव उपकरण में किसी भी अन्य जुड़े घटक की तरह दिखाई देता है, इसमें कोई अतिरिक्त आवरण या ऐसा कुछ भी नहीं है।

मैंने एचओसी के खिलाफ फैसला किया क्योंकि मैं ओओपी/विरासत प्रतिमान को शामिल नहीं करना चाहता था, क्योंकि यह घटक को कुछ और प्रोप प्रदान करने के बारे में है, इसका व्यवहार अन्यथा छूटा हुआ है।

mapStateToProps में वायरिंग करने के बारे में अच्छी बात है। यह काम करेगा लेकिन फिर मेरे पास कम से कम 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 , मैं बस इस बारे में उत्सुक हूं कि किसी को मर्जप्रॉप्स का उपयोग करने से क्यों बचना चाहिए? मुझे mapStateToProps से प्रॉप्स को "छिपाना" बहुत सुविधाजनक लगता है, जिसकी मुझे अपने कार्यों में mapDispatchToProps में आवश्यकता हो सकती है, लेकिन घटक में नहीं। क्या यह एक बुरी बात है?