Redux: لا يشرح مستند "CombinedReducers" كيفية تخمين أي جزء من الحالة يتم تمريره إلى جهاز التروس

تقولها كيندا إذا قرأتها بالكامل ، دون تخطي:

المخفض الناتج يستدعي كل طفل مخفض ، ويجمع نتائجهم في كائن حالة واحد. يتطابق شكل كائن الحالة مع مفاتيح المخفضات التي تم تمريرها.

لكنني أوافق على أن هذا يجب أن يكون أكثر وضوحًا ، حيث غالبًا ما يفوت الناس هذه الجملة.
هل التغييرات من # 399 تساعدك؟

أنا أفضل علوم الكمبيوتر أقل ، ملاحظة صريحة حول هذه الاتفاقية مباشرة بعد المثال:

لاحظ أن المخفضات تسمى todos و counter - تمامًا مثل أجزاء الحالة التي نمررها إليهم.

لتمرير جزء من الحالة إلى المخفض ، تستخدم Redux _convention_ - يجب تسمية المخفض

أعتقد أن # 399 جيد ولكنه شرح لمستخدمي Flux. أنا قادم إلى Redux جديدًا من القارب. قد يكون بعض أشكال النص الخاص بي أكثر فائدة لمطوري JavaScript العاديين.

الفكرة المهمة هنا هي: الاتفاقية جزء من API . من المهم بنفس القدر أن createRedux و createDispatcher وأي وظيفة أخرى لواجهة برمجة التطبيقات. اذكر دائمًا الاتفاقيات صراحة لأنها جزء من واجهة برمجة التطبيقات.

راجع للشغل ، ما زلت في حيرة حول كيفية تمرير جزء فرعي من الحالة إلى المخفض. هل يجب عليّ حالة الجمل أنضم إليهم أم شيء من هذا القبيل؟ state={owner: {name: 'John'} } → export function ownerName(state = [], action) ؟

شكرًا على التعليقات ، إنها قيمة جدًا.

اريد ان اؤكد ذلك

الاتفاقية جزء من API

هذا ليس صحيحًا حقًا.

ربما يجب علينا فقط تجنب استخدام import * في المستندات لأن الناس يفترضون أنه جزء لا يتجزأ من واجهة برمجة التطبيقات عندما لا يكون كذلك على الإطلاق ، وهو مجرد اختصار مناسب أستخدمه.

أسماء الوظائف مهمة فقط بسبب كيفية عمل ES6 export و import * as .

راجع للشغل ، ما زلت في حيرة حول كيفية تمرير جزء فرعي من الحالة إلى المخفض. هل يجب عليّ حالة الجمل أنضم إليهم أم شيء من هذا القبيل؟ state = {owner: {name: 'John'}} → وظيفة التصدير ownerName (state = []، action)؟

رقم :-). إنها ليست واجهة برمجة تطبيقات سحرية. يجمع combineReducers(object) عدة مخفضات في واحد ، ويمرر أجزاء من الحالة إلى قيمها من خلال المفاتيح التي تقدمها. انها تفعل هذا فقط بالضبط مستوى واحد عميق. لا يوجد "سحر بناء شجرة كاملة". الأمر متروك لك لتقسيم المخفض إلى المزيد من الوظائف:

// Function names don't matter!
function processA(state, action) { ... }
function doSomethingWithB(state, action) { ... }

function reducer(state = {}, action) {
  return {
    // Because you call them!
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}

// Not using combineReducers
let store = createStore(reducer);

لا يهم حتى إذا كنت تستخدم المساعد combineReducers طالما أنشأت الكائن بنفسك :

// Function names don't matter!
function processA(state, action) { ... }
function doSomethingWithB(state, action) { ... }

/*
function reducer(state = {}, action) {
  return {
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}
*/
let reducer = combineReducers({
  a: processA,
  b: doSomethingWithB
});

let store = createStore(reducer);

يمكنك القيام بذلك عدة مرات.

قبل:

// Function names don't matter!
function processSomePartOfA(state, action) { ... }
function doSomethingWithOtherPartOfA(state, action) { ... }

function processA(state, action) {
  return {
    // Because you call them!
    somePart: processSomePartOfA(state.somePart),
    otherPart: doSomethingWithOtherPartOfA(state.otherPart)
  }
}
function doSomethingWithB(state, action) { ... }

function reducer(state = {}, action) {
  return {
    // Because you call them!
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}

// Not using the helper
let store = createStore(reducer);

هل ترى؟ إنها مجرد وظائف تستدعي الوظائف. لا توجد "أشياء عميقة" سحرية.
ويمكنك استخدام combineReducers عدة مرات أيضًا:

// Function names don't matter!
function processSomePartOfA(state, action) { ... }
function doSomethingWithOtherPartOfA(state, action) { ... }

/*
function processA(state, action) {
  return {
    somePart: processSomePartOfA(state.somePart),
    otherPart: doSomethingWithOtherPartOfA(state.otherPart)
  }
}
*/
let processA = combineReducers({
  somePart: processSomePartOfA,
  otherPart: doSomethingWithOtherPartOfA
});

function processA(state, action) { ... }
function doSomethingWithB(state, action) { ... }

/*
function reducer(state = {}, action) {
  return {
    a: processA(state.a, action),
    b: doSomethingWithB(state.b, action)
  };
}
*/
let reducer = combineReducers({
  a: processA,
  b: doSomethingWithB
});

let store = createStore(reducer);

الجزء الوحيد الذي تكون فيه أسماء الدوال مهمة هو عندما تستخدم export + import * as "للحصول" على كائن تقوم بتمريره إلى combineReducers لأن هذه هي الطريقة التي يعمل بها import * ! يضع الأشياء في كائن بناءً على مفاتيح التصدير الخاصة بهم.

أعتقد أن خطئي الأكبر هنا هو افتراض أن القارئ على دراية بالصادرات المحددة.

أعتقد أن خطئي الأكبر هنا هو افتراض أن القارئ على دراية بالصادرات المحددة.

أعتقد أن افتراض أن القارئ على دراية بـ ES6 يعد امتدادًا. لكن هذا ما يدفع الناس إلى التعلم واكتشاف هذه الأشياء. لذلك من الجيد حقًا أن تكون القراءة قبل معرفة وخبرة القارئ.

نحن بصدد تغيير الأمثلة لاستدعاء combineReducers بشكل صريح reducers/index لذا نأمل أن يصبح الأمر أكثر منطقية من الآن فصاعدًا: https://github.com/gaearon/redux/pull/473

الإغلاق ، حيث يبدو أنه من الأفضل تناول هذا الأمر في المستندات الحالية.
ولم نعد نستخدم import * في المستندات أيضًا.

هل تعتقد حقًا أن تضمين سلوك ضمني كهذا يعد ممارسة جيدة في الترميز؟

بالنسبة لي ، فإنه يخفي التعتيم على الكود ولا يجب أن يكون موقع CombinedReducer موجودًا ، ويضيف خطوة غير ضرورية من التجريد ويعقد العملية.

عندما تكتب إطار عمل ، يجب أن تكون سمة مهمة مثل هذه سهلة الفهم ، ومن الواضح أن هذا ليس هو الحال ، مثل الشعور "السحري".

ملاحظة: لقد جئت من وثائق Redux الرسمية: "إنه ليس سحرًا"