Redux: नेस्टेड संस्थाओं को अपडेट करते समय बॉयलरप्लेट कैसे काटें?

को निर्मित 3 नव॰ 2015 · 32टिप्पणियाँ · स्रोत: reduxjs/redux

इसलिए मेरे पास मेरे राज्य के तहत यह नेस्टेड संरचना है

state = {
   plans: [
    {title: 'A', exercises: [{title: 'exe1'}, {title: 'exe2'},{title: 'exe3'}]},
    {title: 'B', exercises: [{title: 'exe5'}, {title: 'exe1'},{title: 'exe2'}]}
   ]
}

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

उदाहरण के लिए, यदि मैं एक नया खाली अभ्यास जोड़ना चाहता हूं या किसी मौजूदा को अपडेट करना चाहता हूं, तो डेटा को परिवर्तित करना जो मैं अभी करूंगा:

state.plans[planIdx].exercises.push({})

state.plans[planIdx].exercises[exerciseIdx] = exercise

लेकिन इस नेस्टेड संरचना में वही करने के लिए मेरा सबसे अच्छा तरीका क्या हो सकता है? मैंने Redux डॉक्स और समस्या निवारण भाग को भी पढ़ा है, लेकिन मुझे जो फुर्सत मिली, मैं एक योजना को अपडेट कर रहा था, जहाँ मैं करूँगा:

case 'UPDATE_PLAN':
    return {
      ...state,
      plans: [
      ...state.plans.slice(0, action.idx),
      Object.assign({}, state.plans[action.idx], action.plan),
      ...state.plans.slice(action.idx + 1)
      ]
    };

क्या इसके साथ काम करने का तेज़ तरीका नहीं है? यहां तक कि अगर मुझे बाहरी पुस्तकालयों का उपयोग करना है, या कम से कम अगर कोई मुझे समझा सकता है कि इससे बेहतर कैसे निपटें ...

धन्यवाद!

docs question

स्रोत

andre0799

👍20

सबसे उपयोगी टिप्पणी

हां, हम आपका डेटा सामान्य करने का सुझाव देते हैं।
इस तरह आपको "गहरे" जाने की ज़रूरत नहीं है: आपकी सभी इकाइयाँ समान स्तर पर हैं।

तो आपका राज्य कैसा लगेगा

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 1, 2]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
    }
  },
  currentPlans: [1, 2]
}

आपके रिड्यूसर दिख सकते हैं

import merge from 'lodash/object/merge';

const exercises = (state = {}, action) => {
  switch (action.type) {
  case 'CREATE_EXERCISE':
    return {
      ...state,
      [action.id]: {
        ...action.exercise
      }
    };
  case 'UPDATE_EXERCISE':
    return {
      ...state,
      [action.id]: {
        ...state[action.id],
        ...action.exercise
      }
    };
  default:
    if (action.entities && action.entities.exercises) {
      return merge({}, state, action.entities.exercises);
    }
    return state;
  }
}

const plans = (state = {}, action) => {
  switch (action.type) {
  case 'CREATE_PLAN':
    return {
      ...state,
      [action.id]: {
        ...action.plan
      }
    };
  case 'UPDATE_PLAN':
    return {
      ...state,
      [action.id]: {
        ...state[action.id],
        ...action.plan
      }
    };
  default:
    if (action.entities && action.entities.plans) {
      return merge({}, state, action.entities.plans);
    }
    return state;
  }
}

const entities = combineReducers({
  plans,
  exercises
});

const currentPlans = (state = [], action) {
  switch (action.type) {
  case 'CREATE_PLAN':
    return [...state, action.id];
  default:
    return state;
  }
}

const reducer = combineReducers({
  entities,
  currentPlans
});

तो यहां क्या हो रहा है? सबसे पहले, ध्यान दें कि राज्य सामान्यीकृत है। हमारे पास कभी भी अन्य संस्थाओं के अंदर की संस्थाएं नहीं हैं। इसके बजाय, वे एक-दूसरे को आईडी द्वारा संदर्भित करते हैं। इसलिए जब भी कोई वस्तु बदलती है, तो बस एक ही जगह होती है, जहां इसे अपडेट करने की आवश्यकता होती है।

दूसरा, ध्यान दें कि कैसे हम plans reducer में एक उपयुक्त इकाई जोड़कर CREATE_PLAN प्रतिक्रिया करते हैं _and_ अपनी ID को currentPlans reducer में जोड़कर। यह महत्वपूर्ण है। अधिक जटिल ऐप्स में, आपके संबंध हो सकते हैं, जैसे plans reducer ADD_EXERCISE_TO_PLAN को उसी तरह से प्रबंधित कर सकता है जैसे प्लान के अंदर सरणी में एक नई ID जोड़कर। लेकिन अगर व्यायाम खुद ही अपडेट हो जाता है, तो _there को यह जानने के लिए plans reducer की आवश्यकता नहीं है, क्योंकि ID ने_ नहीं बदला है।

तीसरा, ध्यान दें कि इकाइयाँ reducers ( plans और exercises ) action.entities लिए बाहर देखने वाले विशेष खंड हैं। ऐसा तब होता है जब हमारे पास "ज्ञात सत्य" के साथ एक सर्वर प्रतिक्रिया होती है जिसे हम प्रतिबिंबित करने के लिए अपनी सभी संस्थाओं को अपडेट करना चाहते हैं। किसी कार्रवाई को भेजने से पहले अपना डेटा इस तरह से तैयार करने के लिए, आप नॉर्मिज़र का उपयोग कर सकते हैं। आप इसे Redux रेपो में "वास्तविक दुनिया" उदाहरण में उपयोग कर सकते हैं।

अंत में, नोटिस करें कि रिड्यूसर कैसे समान हैं। आप उन्हें उत्पन्न करने के लिए एक फ़ंक्शन लिखना चाहते हैं। यह मेरे उत्तर के दायरे से बाहर है - कभी-कभी आप अधिक लचीलापन चाहते हैं, और कभी-कभी आप कम बॉयलरप्लेट चाहते हैं। आप "वास्तविक दुनिया" उदाहरण reducers में समान reducers बनाने के उदाहरण के लिए पेजिनेशन कोड देख सकते हैं।

ओह, और मैंने { ...a, ...b } सिंटैक्स का उपयोग किया। यह ES7 प्रस्ताव के रूप में बाबेल चरण 2 में सक्षम है। इसे "ऑब्जेक्ट स्प्रेड ऑपरेटर" कहा जाता है और Object.assign({}, a, b) लिखने के बराबर है।

पुस्तकालयों के लिए के रूप में, आप Lodash उपयोग कर सकते हैं (हालांकि उत्परिवर्तित के प्रति सावधान, जैसे होना merge({}, a, b} सही है लेकिन merge(a, b) , नहीं है) updeep , प्रतिक्रिया-एडऑन अद्यतन या कुछ और। हालाँकि यदि आप अपने आप को गहरे अपडेट करने की आवश्यकता महसूस करते हैं, तो इसका मतलब है कि आपका राज्य वृक्ष पर्याप्त सपाट नहीं है, और यह कि आप कार्यात्मक संरचना का पर्याप्त उपयोग नहीं करते हैं। यहां तक कि आपका पहला उदाहरण:

case 'UPDATE_PLAN':
  return {
    ...state,
    plans: [
      ...state.plans.slice(0, action.idx),
      Object.assign({}, state.plans[action.idx], action.plan),
      ...state.plans.slice(action.idx + 1)
    ]
  };

के रूप में लिखा जा सकता है

const plan = (state = {}, action) => {
  switch (action.type) {
  case 'UPDATE_PLAN':
    return Object.assign({}, state, action.plan);
  default:
    return state;
  }
}

const plans = (state = [], action) => {
  if (typeof action.idx === 'undefined') {
    return state;
  }
  return [
    ...state.slice(0, action.idx),
    plan(state[action.idx], action),
    ...state.slice(action.idx + 1)
  ];
};

// somewhere
case 'UPDATE_PLAN':
  return {
    ...state,
    plans: plans(state.plans, action)
  };

gaearon 3 नव॰ 2015

👍137 ❤52 🎉2

सभी 32 टिप्पणियाँ

यह नेस्टेड JSON को सामान्य करने के लिए अनुशंसित है: https://github.com/gaearon/normalizr

hulufei 3 नव॰ 2015

तो आपका राज्य कैसा लगेगा

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 1, 2]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
    }
  },
  currentPlans: [1, 2]
}

आपके रिड्यूसर दिख सकते हैं

import merge from 'lodash/object/merge';

const exercises = (state = {}, action) => {
  switch (action.type) {
  case 'CREATE_EXERCISE':
    return {
      ...state,
      [action.id]: {
        ...action.exercise
      }
    };
  case 'UPDATE_EXERCISE':
    return {
      ...state,
      [action.id]: {
        ...state[action.id],
        ...action.exercise
      }
    };
  default:
    if (action.entities && action.entities.exercises) {
      return merge({}, state, action.entities.exercises);
    }
    return state;
  }
}

const plans = (state = {}, action) => {
  switch (action.type) {
  case 'CREATE_PLAN':
    return {
      ...state,
      [action.id]: {
        ...action.plan
      }
    };
  case 'UPDATE_PLAN':
    return {
      ...state,
      [action.id]: {
        ...state[action.id],
        ...action.plan
      }
    };
  default:
    if (action.entities && action.entities.plans) {
      return merge({}, state, action.entities.plans);
    }
    return state;
  }
}

const entities = combineReducers({
  plans,
  exercises
});

const currentPlans = (state = [], action) {
  switch (action.type) {
  case 'CREATE_PLAN':
    return [...state, action.id];
  default:
    return state;
  }
}

const reducer = combineReducers({
  entities,
  currentPlans
});

case 'UPDATE_PLAN':
  return {
    ...state,
    plans: [
      ...state.plans.slice(0, action.idx),
      Object.assign({}, state.plans[action.idx], action.plan),
      ...state.plans.slice(action.idx + 1)
    ]
  };

के रूप में लिखा जा सकता है

const plan = (state = {}, action) => {
  switch (action.type) {
  case 'UPDATE_PLAN':
    return Object.assign({}, state, action.plan);
  default:
    return state;
  }
}

const plans = (state = [], action) => {
  if (typeof action.idx === 'undefined') {
    return state;
  }
  return [
    ...state.slice(0, action.idx),
    plan(state[action.idx], action),
    ...state.slice(action.idx + 1)
  ];
};

// somewhere
case 'UPDATE_PLAN':
  return {
    ...state,
    plans: plans(state.plans, action)
  };

gaearon 3 नव॰ 2015

👍137 ❤52 🎉2

इसे एक नुस्खा में बदलना अच्छा होगा।

gaearon 3 नव॰ 2015

👍10

आदर्श रूप से हम एक कंबन बोर्ड उदाहरण चाहते हैं।
यह नेस्टेड संस्थाओं के लिए एकदम सही है क्योंकि "लेन" में उनके अंदर "कार्ड" हो सकते हैं।

gaearon 3 नव॰ 2015

👍4

@ (re0799 या आप बस

smashercosmo 3 नव॰ 2015

👎15 😄5 😕3 👍2 🚀1 🎉1

आदर्श रूप से हम एक कंबन बोर्ड उदाहरण चाहते हैं।

मैंने एक लिखा

bebraw 3 नव॰ 2015

👍3

अपरिवर्तनीय.जेएस हमेशा एक अच्छा समाधान नहीं है। यह आपके द्वारा बदले गए नोड से शुरू होने वाले राज्य के प्रत्येक मूल नोड के हैश का पुनरावर्तक करता है और जो विशेष मामलों में अड़चन बन जाता है (यह बहुत सामान्य मामले नहीं है)। इसलिए आदर्श रूप से आपको अपने आवेदन में Immutable.js को एकीकृत करने से पहले कुछ बेंचमार्क बनाने चाहिए।

chicoxyzzy 3 नव॰ 2015

👍3

आपके उत्तर के लिए धन्यवाद @gaearon , बढ़िया व्याख्या!

andre0799 4 नव॰ 2015

इसलिए, जब आप CREATE_PLAN करते हैं, तो आपको स्वचालित रूप से एक डिफ़ॉल्ट व्यायाम बनाना चाहिए और इसे जोड़ना चाहिए। मुझे इस तरह के मामलों को कैसे संभालना चाहिए? क्या मुझे एक पंक्ति में 3 कार्य करने चाहिए? CREATE_PLAN, CREATE_EXERCISE, ADD_EXERCISE_TO_PLAN मुझे ये कॉल कहां से करना चाहिए, अगर ऐसा है?

andre0799 4 नव॰ 2015

इसलिए, जब आप CREATE_PLAN करते हैं, तो आपको स्वचालित रूप से एक डिफ़ॉल्ट व्यायाम बनाना चाहिए और इसे जोड़ना चाहिए। मुझे इस तरह के मामलों को कैसे संभालना चाहिए?

जबकि आम तौर पर मैं एक ही कार्रवाई को संभालने वाले कई रेड्यूसर के पक्ष में हूं, यह रिश्तों के साथ संस्थाओं के लिए बहुत जटिल हो सकता है। दरअसल, मैं इन्हें अलग-अलग कार्यों के रूप में मॉडल करने का सुझाव दे रहा हूं।

आप Redux Thunk मिडलवेयर का उपयोग उन दोनों को कॉल करने वाले एक्शन क्रिएटर को लिखने के लिए कर सकते हैं:

function createPlan(title) {
  return dispatch => {
    const planId = uuid();
    const exerciseId = uuid();

    dispatch({
      type: 'CREATE_EXERCISE',
      id: exerciseId,
      exercise: {
        id: exerciseId,
        title: 'Default'
      }
    });

    dispatch({
      type: 'CREATE_PLAN',
      id: planId,
      plan: {
        id: planId,
        exercises: [exerciseId],
        title
      }
    });
  };
}

फिर, यदि आप Redux Thunk मिडलवेयर लागू करते हैं, तो आप इसे सामान्य रूप से कॉल कर सकते हैं:

store.dispatch(createPlan(title));

gaearon 4 नव॰ 2015

👍12 ❤1

तो चलिए बताते हैं कि इस तरह के रिश्तों (पोस्ट, लेखक, टैग, अटैचमेंट आदि) के साथ बैकएंड पर मेरा एक पोस्ट एडिटर है।

मैं currentPosts currentPlans कुंजियों के समान प्रदर्शित करने के बारे में कैसे जाऊँ? मैं में प्रत्येक कुंजी मैप करने के लिए की आवश्यकता होगी currentPosts में अपनी इसी वस्तु के लिए entities.posts में mapStateToProps समारोह? currentPosts छंटनी के बारे में कैसे?

क्या यह सब एक reducer रचना में है?

मुझे यहाँ कुछ याद आ रहा है ...

mikebarnhardt 4 नव॰ 2015

मूल प्रश्न के बारे में, मेरा मानना है कि रिएक्ट इम्युटेबिलिटी हेल्पर्स उस उद्देश्य के लिए बनाए गए थे

kolodny 4 नव॰ 2015

👍3

मैं करंटपॉल्स की वर्तमान सरणी के समान करंटपॉस्ट प्रदर्शित करने के बारे में कैसे जाऊँ? क्या मुझे currentPosts में प्रत्येक कुंजी को उसके संबंधित ऑब्जेक्ट के लिए मैप करने की आवश्यकता होगी। करेंटपॉइंट को कैसे सॉर्ट करें?

यह सही है। डेटा प्राप्त करते समय आप सब कुछ करेंगे। कृपया "शॉपिंग कार्ट" और "वास्तविक दुनिया" उदाहरणों से परामर्श करें जो Redux रेपो के साथ आते हैं।

gaearon 4 नव॰ 2015

धन्यवाद, मैंने पहले ही डॉक्स पर कम्प्यूटिंग व्युत्पन्न डेटा पढ़ने के बाद एक विचार प्राप्त करना शुरू कर दिया है।

मैं उन उदाहरणों की फिर से जाँच करूँगा। जब मैं उन्हें पढ़ता था तो मुझे बहुत कुछ समझ में नहीं आता था कि पहले क्या हो रहा था।

mikebarnhardt 4 नव॰ 2015

@ andre0799

किसी भी connect() एड कंपोनेंट में dispatch डिफ़ॉल्ट रूप से प्रॉप के रूप में इंजेक्ट किया जाता है।

this.props.dispatch(createPlan(title));

यह एक उपयोग प्रश्न है जो इस थ्रेड से असंबंधित है। इसके लिए उदाहरणों से परामर्श करना या इसके लिए StackOverflow प्रश्न बनाना बेहतर है।

gaearon 4 नव॰ 2015

मैं डेटा को सामान्य करने और यथासंभव राज्य संरचना को समतल करने के साथ डैन से सहमत हूं। इसे दस्तावेज़ीकरण में एक नुस्खा / सर्वोत्तम अभ्यास के रूप में रखा जा सकता है, क्योंकि इसने मुझे कुछ सिरदर्द से बचाया होगा।

जैसा कि मैंने अपने राज्य में थोड़ी गहराई होने की गलती की है, मैंने Redux के साथ गहरी स्थिति को फिर से बनाने और प्रबंधित करने में मदद करने के लिए यह दायित्व बनाया: https://github.com/baptistemanson/immutable-path
शायद मुझे यह सब गलत लगा लेकिन मुझे आपकी प्रतिक्रिया के साथ दिलचस्पी होगी। आशा है कि यह किसी की मदद करेगा।

baptistemanson 6 नव॰ 2015

यह मददगार था। सभी को धन्यवाद।

ericdfields 13 जन॰ 2016

वास्तविक दुनिया के उदाहरण के समान संरचना का उपयोग करते हुए, आप किसी योजना में व्यायाम को कैसे जोड़ेंगे? मान लीजिए कि एक व्यायाम जोड़ने से planId फ़ील्ड के साथ, नई बनाई गई व्यायाम इकाई वापस आ गई। क्या योजनाओं के लिए एक reducer लिखने के बिना उस योजना में नया अभ्यास जोड़ना संभव है, और विशेष रूप से CREATE_EXERCISE कार्रवाई के लिए सुनो?

tmonte 1 फ़र॰ 2016

बड़ी चर्चा और जानकारी यहाँ। मैं अपने प्रोजेक्ट के लिए नॉर्मिज़्र का उपयोग करना चाहूंगा, लेकिन अपडेटेड डेटा को रिमोट सर्वर पर सहेजने के संबंध में एक प्रश्न है। मुख्य रूप से, क्या सामान्य आकार को फिर से अद्यतन करने के बाद दूरस्थ एपीआई द्वारा प्रदान की गई नेस्टेड आकृति को वापस करने का सरल तरीका है? यह महत्वपूर्ण है जब क्लाइंट परिवर्तन करता है और इसे दूरस्थ एपी में वापस फीड करने की आवश्यकता होती है जहां अद्यतन अनुरोध के आकार पर उसका कोई नियंत्रण नहीं है।

उदाहरण के लिए: क्लाइंट नेस्टेड एक्सरसाइज डेटा प्राप्त करता है -> क्लाइंट इसे सामान्य करता है और इसे redux में स्टोर करता है -> उपयोगकर्ता क्लाइंट साइड पर सामान्यीकृत डेटा में बदलाव करता है -> यूजर क्लिक्स सेव -> क्लाइंट ऐप अपडेटेड सामान्यीकृत डेटा को n n फॉर्म में वापस बदल देता है। इसलिए यह इसे रिमोट सर्वर पर जमा कर सकता है -> क्लाइंट सर्वर को सबमिट करता है

अगर मैं सामान्य तौर पर इस्तेमाल करता हूं, तो मुझे बोल्ड स्टेप के लिए एक कस्टम ट्रांसफॉर्मर लिखने की जरूरत होगी या क्या आप इसके लिए कोई लाइब्रेरी या हेल्पर विधि सुझाएंगे? किसी भी सिफारिश की बहुत सराहना की जाएगी।

धन्यवाद

pacjin79 10 मई 2016

👍2

वहाँ कुछ कहा जाता है https://github.com/gpbl/denormalizr लेकिन मुझे यकीन नहीं है कि यह सामान्य अपडेट को कितनी बारीकी से ट्रैक करता है। मैंने जिस ऐप पर काम किया है, उसके लिए मैंने कुछ घंटों में नॉर्मिज़र लिखा, आप इसका स्वागत करते हैं और इसे जोड़ते हैं।

gaearon 10 मई 2016

❤1 😄1 👍1

कूल मैं निश्चित रूप से वियोग पर एक नज़र डालूंगा और कुछ होने के बाद अपनी परियोजना में वापस योगदान दूंगा। कुछ घंटों के लिए महान काम ;-) मेरे पास वापस आने के लिए धन्यवाद।

pacjin79 11 मई 2016

मैं गहरी नेस्टेड डेटा को बदलने के साथ एक ही स्थिति में हूं, हालांकि, मैंने अपरिवर्तनीय.जेएस का उपयोग करके एक कार्यशील समाधान पाया है।

क्या यह ठीक है अगर मैं एक StackOverflow पोस्ट से जुड़ता हूं जो मैंने यहां समाधान पर प्रतिक्रिया के लिए पूछ रहा है?

मैं इसे अभी के लिए लिंक कर रहा हूं, कृपया मेरी पोस्ट हटाएं या कहें कि यहां लिंक करना अनुचित है:
http://stackoverflow.com/questions/37171203/manipulating-data-in-nested-arrays-in-redux-with-immutable-js

MathiasKahlen 12 मई 2016

मैंने देखा है कि इस दृष्टिकोण को अतीत में अनुशंसित किया जा रहा है। हालाँकि, जब कोई नेस्टेड ऑब्जेक्ट को निकालने की आवश्यकता होती है, तो यह दृष्टिकोण अच्छी तरह से काम नहीं करता है। इस मामले में, reducer को ऑब्जेक्ट के सभी संदर्भों को देखने और उन्हें हटाने की आवश्यकता होगी, एक ऑपरेशन जो ओ (एन) होगा, ऑब्जेक्ट को हटाने में सक्षम होने से पहले। किसी को भी इसी तरह की समस्या में भाग गया और इसे हल किया?

ariofrio 14 जुल॰ 2016

@ariofrio : आह ... मैं उलझन में हूँ। सामान्यीकरण की बात यह है कि ऑब्जेक्ट _not_ संग्रहीत नेस्टेड हैं, और किसी दिए गए आइटम का केवल एक संदर्भ है, जिससे उस आइटम को अपडेट करना आसान हो जाता है। अब, अगर वहाँ कई अन्य संस्थाएं हैं जो आईडी द्वारा इस आइटम को "संदर्भित" करते हैं, तो निश्चित रूप से, उन्हें उसी तरह अपडेट किया जाना चाहिए, जैसे कि चीजें सामान्यीकृत नहीं थीं।

क्या आपके पास एक विशिष्ट चिंता है, या एक परेशानी वाला परिदृश्य जो आप के साथ काम कर रहे हैं?

markerikson 14 जुल॰ 2016

यही है जो मेरा मतलब है। कहते हैं कि वर्तमान स्थिति जैसी दिखती है:

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 6]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
      5: {title: 'exe5'}
      6: {title: 'exe6'}
    }
  },
  currentPlans: [1, 2]
}

इस उदाहरण में, प्रत्येक अभ्यास को केवल एक योजना द्वारा संदर्भित किया जा सकता है। जब उपयोगकर्ता "व्यायाम हटाएं" पर क्लिक करता है, तो संदेश कुछ इस तरह दिखाई दे सकता है:

{type: "REMOVE_EXERCISE", payload: 2}

लेकिन इसे ठीक से लागू करने के लिए, सभी को सभी योजनाओं पर पुनरावृति करने की आवश्यकता होगी, और फिर प्रत्येक योजना के भीतर सभी अभ्यास करने के लिए, जिसे एक झंझट से बचने के लिए आईडी 2 के साथ व्यायाम का संदर्भ दिया गया था। यह ओ (एन) ऑपरेशन है जिसके बारे में मैं चिंतित था।

इससे बचने का एक तरीका यह है कि योजना आईडी को REMOVE_EXERCISE के पेलोड में शामिल किया जाए, लेकिन इस बिंदु पर, मुझे संरचनाओं के घोंसले का उपयोग करने पर फायदा नहीं दिखता है। यदि हमने इसके बजाय नेस्टेड राज्य का उपयोग किया है, तो राज्य ऐसा दिख सकता है:

{
   plans: [
    {title: 'A', exercises: [{title: 'exe1'}, {title: 'exe2'},{title: 'exe3'}]},
    {title: 'B', exercises: [{title: 'exe5'}, {title: 'exe6'}]}
   ]
}

और व्यायाम को हटाने के लिए संदेश की तरह लग सकता है:

{type: "REMOVE_EXERCISE", payload: {plan_index: 0, exercise_index: 1}}

ariofrio 14 जुल॰ 2016

👍7

कुछ विचार:

आप उस परिदृश्य को सरल बनाने की योजना के लिए अभ्यासों का एक रिवर्स लुकअप बनाए रख सकते हैं। इसी तरह, कई प्रकार के संबंधों के लिए Redux-ORM लाइब्रेरी जो "टेबल के माध्यम से" ऑटो-जेनरेट करती है। तो, इस मामले में आपके स्टोर में एक "PlanExercise" "टेबल" होगा, जिसमें {id, planId, exerciseId} ट्रिपल शामिल होंगे। निश्चित रूप से एक ओ (एन) स्कैन, लेकिन एक सीधा।
O (n) ऑपरेशन स्वाभाविक रूप से एक बुरी चीज नहीं है। यह पूरी तरह से इस बात पर निर्भर करता है कि एन कितना बड़ा है, शब्द के सामने स्थिर कारक, यह कितनी बार होता है, और आपके आवेदन में और क्या चल रहा है। 10 या 15 आइटमों की सूची में बदलाव करना और उपयोगकर्ता बटन पर कुछ समानता की जाँच करना, पूरी तरह से अलग बात होने जा रही है, कहते हैं, हर 500ms में सिस्टम में आने वाली 10M वस्तुओं की सूची को पुनरावृत्त करना और प्रत्येक के लिए कुछ महंगा ऑपरेशन करना आइटम। इस मामले में, ऑड्स हैं कि हजारों योजनाओं के माध्यम से भी जाँच करना एक महत्वपूर्ण सार्थक अड़चन नहीं होगी।
क्या यह एक वास्तविक प्रदर्शन चिंता है जिसे आप देख रहे हैं, या केवल संभावित सैद्धांतिक मुद्दों के लिए आगे देख रहे हैं?

अंततः, दोनों नेस्टेड और सामान्यीकृत राज्य कन्वेंशन हैं। Redux के साथ सामान्यीकृत स्थिति का उपयोग करने के अच्छे कारण हैं, और आपके राज्य को सामान्य रखने के लिए अच्छे कारण हो सकते हैं। जो भी आपके लिए काम करता है उठाओ :)

markerikson 14 जुल॰ 2016

👍1

इस तरह मेरा समाधान:

function deepCombinReducer(parentReducer, subReducer) {
    return function (state = parentReducer(void(0) /* get parent reducer initial state */, {}) {
        let finalState = {...state};

        for (var k in subReducer) {
          finalState[k] = subReducer(state[k], action);
        }

       return parentReducer(finalState, action);
    };
}

const parentReducer = function(state = {}, action) {
    return state;
}

const subReducer = function(state = [], action) {
    state = Immutable.fromJS(state).toJS();
    switch(action.type) {
       case 'ADD':
          state.push(action.sub);
           return state;
       default:
          return state;
   }
}

export default combineReducers({
   parent: deepCombinReducer(parentReducer, {
       sub: subReducer
   })
})

फिर, आप इस तरह से स्टोर प्राप्त कर सकते हैं:

{
    parent: {
       sub: []
    }
}

dispatch({
    type: 'ADD',
    sub: '123'
});

// the store will change to:
{
    parent: {
       sub: ['123']
    }
}

cage1618 18 नव॰ 2016

@smashercosmo immutable.js गहरी नेस्टेड अवस्था के साथ? मैं उत्सुक हूं कि कैसे

wzup 6 दिस॰ 2016

@gaearon

हमारे पास कभी भी अन्य संस्थाओं के अंदर की संस्थाएं नहीं हैं।

मैं इसे नहीं समझता। हमारे यहां कम से कम तीन स्तर के घोंसले हैं:

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 1, 2]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
    }
  },
  currentPlans: [1, 2]
}

entities.plans[1] - three levels
entities.exercises[1] - three levels

यह एक नेस्टेड ऑब्जेक्ट नहीं है। केवल एक स्तर।

{
   plans: [1,2, 3],
   exercises: [1,2,3],
   'so forth': [1,2,3]
}

wzup 6 दिस॰ 2016

@wzup : FYI करें, Dan इन दिनों Redux के मुद्दों को देखने में ज्यादा समय नहीं देता है - वह रिएक्ट पर काम करने वाली अपनी प्लेट पर पर्याप्त है।

यहां "नेस्टिंग" का अर्थ है जब डेटा स्वयं नेस्टेड है, जैसे कि थ्रेड में पहले से यह उदाहरण:

{
   plans: [
    {title: 'A', exercises: [{title: 'exe1'}, {title: 'exe2'},{title: 'exe3'}]},
    {title: 'B', exercises: [{title: 'exe5'}, {title: 'exe6'}]}
   ]
}

उस उदाहरण में, व्यायाम "एक्सई 6" तक पहुंचने का एकमात्र तरीका संरचना में खुदाई करना है, जैसे plans[1].exercises[2] ।

markerikson 6 दिस॰ 2016

मुझे @tmonte के सवाल में दिलचस्पी है:

वास्तविक दुनिया के उदाहरण के समान संरचना का उपयोग करते हुए, आप किसी योजना में व्यायाम को कैसे जोड़ेंगे? मान लें कि एक व्यायाम को जोड़ने से एक योजनाबद्ध क्षेत्र के साथ नव निर्मित व्यायाम इकाई वापस आ गई। क्या योजनाओं के लिए एक reducer लिखने के बिना उस योजना में नया अभ्यास जोड़ना संभव है, और विशेष रूप से एक CREATE_EXITEF कार्रवाई के लिए सुनो?

जब आपके पास कई संस्थाएं हैं, तो प्रत्येक इकाई के लिए एक reducer बनाना दर्दनाक हो सकता है, लेकिन यह दृष्टिकोण इसे हल कर सकता है। मुझे अब तक इसका कोई हल नहीं मिला है।

bzuker 17 दिस॰ 2016

👍1

मैं presonnaly का उपयोग mergeWith के बजाय merge अधिक लचीलेपन के लिए:

import mergeWith from 'lodash/mergeWith';

// Updates an entity cache in response to any action with `entities`.
function entities(state = {}, action) {
  // Here where we STORE or UPDATE one or many entities
  // So check if the action contains the format we will manage
  // wich is `payload.entities`
  if (action.payload && action.payload.entities) {
    // if the entity is already in the store replace
    // it with the new one and do not merge. Why?
    // Assuming we have this product in the store:
    //
    // products: {
    //   1: {
    //     id: 1,
    //     name: 'Awesome product name',
    //     rateCategory: 1234
    //   }
    // }
    //
    // We will updated with
    // products: {
    //   1: {
    //     id: 1,
    //     name: 'Awesome product name',
    //   }
    // }
    //
    // The result if we were using `lodash/merge`
    // notice the rate `rateCategory` hasn't changed:
    // products: {
    //   1: {
    //     id: 1,
    //     name: 'Awesome product name',
    //     rateCategory: 1234
    //   }
    // }
    // for this particular use case it's safer to use
    // `lodash/mergeWith` and skip the merge
    return mergeWith({}, state, action.payload.entities, (oldD, newD) => {
      if (oldD && oldD.id && oldD.id === newD.id) {
        return newD;
      }
      return undefined;
    });
  }

  // Here you could register other handlers to manipulate 
  // the entities
  switch (action.type) {
    case ActionTypes.SOME_ACTION:
      // do something;
    default:
      return state;
  }
}

const rootReducer = combineReducers({
  entities,
});
export default rootReducer;

devmarwen 9 सित॰ 2017

👍1

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Redux: नेस्टेड संस्थाओं को अपडेट करते समय बॉयलरप्लेट कैसे काटें?

सबसे उपयोगी टिप्पणी

सभी 32 टिप्पणियाँ

संबंधित मुद्दों