Redux: كيفية تهيئة الإعادة بجسم غير قابل للتغيير

أعتقد أن ما تريده هو شيء من هذا القبيل

// stores/some-store.js
import Immutable from 'immutable'

const { Map, List, fromJS } = Immutable
const initialState = Map({
  foo: 'bar',
  fooList: List()
})

export function someStore (state = initialState, action) {
  if (action.type === 'FOO') {
    return state.set('foo', fromJS(action.foo))
  }
  if (action.type === 'FOO_LIST') {
    return state.set('fooList', fromJS(action.fooList))
  }

  return state
}

// stores/index.js
export { default as someStore } from './some-store'

// application.js
import * as stores from './stores'

const redux = createRedux(stores)

يجب أن تدع المتاجر تحدد حالتها الأولية باستخدام المعلمة الافتراضية مثل emmenko أظهر.

الوسيطة initialState مخصصة فقط لاستخدامها في إعادة الترطيب من الخادم أو localStorage. ( acdlite ، قد نرغب في توضيح ذلك في المستندات.)

ومع ذلك ، فإن ما جربته يجب أن ينجح. يمكن لشخص ما التحقيق؟

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

أريد فقط إنشاء بيانات أولية لجميع المتاجر في مكان واحد. أعتقد أن هذا ما لا يجب أن أفعله.

الأمر متروك لك. أجد أنه من الأفضل تقسيم البيانات الأولية.

ومع ذلك ، إذا لم يعمل شيء ما ، فلنبقه مفتوحًا؟ سأعيد الزيارة الأسبوع المقبل وأرى لماذا لم ينجح ذلك.

تكمن المشكلة في composeStores التي تفترض أن الحالة الجذر هي كائن JS عادي ، والوصول إلى الخصائص باستخدام state[key] ، والذي فشل مع Immutable.Map . أعتقد أنه قد يعمل مع Immutable.Record لأن ذلك يجعل الحقول قابلة للوصول عبر خصائص JS العادية.

قد تكون هناك أماكن أخرى حيث يفترض وجود كائن عادي.

يا. هذا صيد رائع! شكرا للتوضيح. هذا منطقي تمامًا.

فشل استخدام الموصلات أيضًا للسبب نفسه: isPlainObject(Immutable.Record) === false .

pierregm هذا صحيح بالفعل. إذا نشرت خصائص السجل على خاصيات المكون ، فلن يعمل ذلك على أي حال. الأمر متروك لك لكتابة select={state => state.get('something').toJS()} .

تمكنت من جعله يعمل بهذا الشكل ،

// store
const initialState = Immutable.fromJS({}).toOrderedMap();

export default function streamStore(state = initialState, action) {
  switch (action.type) {

    case actionTypes.FETCH_STREAM_DONE:
      var streamMap = {};

      for (var i in action.stream_data) {
        var item = action.stream_data[i];
        streamMap[item.id] = item;
      }
      return state.merge(Immutable.fromJS(streamMap).toOrderedMap());

    default:
      return state
  }
};

// select
function select(state) {
  return {stream: state.stream.toList()}
}

إنه يعمل بشكل مثالي ولكنه ينتهي بإعادة عرض جميع العناصر في الدفق (عرض قائمة). كنت أتساءل كيف يمكن للمرء أن ينفذ شيئًا يقارن بين الحالة القديمة والحالة الجديدة على مستوى المتجر ويلغي الحاجة إلى تقديم أي مكونات هناك عندما لا تكون هناك تغييرات على البيانات. تقوم شركة NuclearJS بذلك باستخدام الهياكل الثابتة. ما هي الطريقة الموصى بها لتنفيذ شيء من هذا القبيل في إعادة؟

@أويس

تحقق من إعادة التحديد: https://github.com/faassen/reselect. إنه يوفر وظائف مشابهة لمكتسبات NuclearJS.

تضمين التغريدة حديث رائع في ReactEurope BTW! شكر.

هذه محاولتي لاستخدام Immutable.js مع redux 1.0.0 ، https://github.com/gajus/redux-immutable

gajus لطيف! اختبر redux-immutable الآن وأعجب حقًا بنمط https://github.com/gajus/canonical-reducer-composition

شكرا لك chiplay. سأكون ممتنًا حقًا للتعليقات إذا واجهت أوجه قصور أو كانت لديك أفكار للتحسين.

هل هناك فائدة من استخدام الهياكل الثابتة مع الإعادة؟ عندما يعتمد الإعادة على سلوك ثابت (على سبيل المثال ، تقوم المتاجر بإرجاع نسخة جديدة من الحالة)؟ الأداء (أي معايير؟)؟ أو أي شيء آخر؟ شكرا

تضمين التغريدة

مميزات استخدام غير قابل للتغيير مع Redux:

• لا يمكنك التحول عن طريق الخطأ
• طريقة أداء أسرع واستهلاك ذاكرة أفضل مع مصفوفات وكائنات كبيرة

سلبيات استخدام غير قابل للتغيير مع Redux:

• واجهة برمجة تطبيقات جديدة للتعلم لفريقك
• زيادة حجم الحزمة
• أصعب قليلاً في التصحيح

المقايضة متروك لك!

تضمين التغريدة
شكرا جزيلا على الإجابة السريعة والمفيدة!

إذا كنت تريد ImmutableJs & Redux التي تتوافق مع معايير Redux ، يمكنك إلقاء نظرة على https://github.com/indexiatech/redux-immutablejs ،

gaearon هل من الممكن وضع رابط على موقع الويب؟

شكرا عساف. أنا متأكد من أن الناس سيجدونها مفيدة.

في 4 سبتمبر 2015 ، الساعة 18:36 ، كتب آصف شكارشي [email protected] :

إذا كنت تريد ImmutableJs & Redux التي تتوافق مع معايير Redux ، يمكنك إلقاء نظرة على https://github.com/indexiatech/redux-immutablejs ،

gaearon هل من الممكن وضع رابط على موقع الويب؟

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub.

@ عساف

أشياء جيدة ، هل ترغب في عمل علاقات عامة على Ecosystem.md ؟
سأضيفها هناك لحسن الحظ إذا أضفت اختبارات إلى مشروعك.

gaearon مع اختبارات الوحدة ، العلاقات العامة هي: https://github.com/rackt/redux/pull/707

شكر!

تحية للجميع،
سؤال بسيط لـ gaearon ، من الاختبارات السريعة التي أجريتها حتى الآن لتطبيق تطبيق React / Redux الحالي ، يبدو الأمر أبطأ قليلاً: - / ولكن ربما أفعل شيئًا بطريقة خاطئة ...

حالة الاستخدام الأساسية: الحصول على مجموعة من البيانات من استدعاء API وتخزينها في مخفض ...

من المخفض الخاص بي ،
بدون ثابت JS:

const initialStore = {
    isLoading : false,
    error     : null,
    data      : []
}

// in the switch case
return {
   ...state,
   isLoading: false,
   error: null,
   data: action.result
}

مع ImmutableJS

const initialStore = Map({
    isLoading : false,
    error     : null,
    data      : List()
})

// in the handler function
return state.merge({
    isLoading: false,
    error: null,
    data: List(result.result)
})

أتساءل ما إذا كان العلاج الذي تقدمه شركة ImmutableJS لا يكلف أكثر هنا؟

مما أفهمه من الثبات ، تكون الفائدة أكثر عندما يكون العرض سريعًا ، أليس كذلك؟

شكرا لملاحظاتك.

وتتمثل الفائدة في أن التشغيل على المصفوفات والكائنات الكبيرة يكلف ذاكرة أقل ويعمل بشكل أسرع. لا يحدث فرقًا كبيرًا في التطبيقات الصغيرة.

حسنا، شكرا.
إذن لدي النهج الصحيح على أي حال؟

نعم ، تبدو جيدة بالنسبة لي.

حتى الآن كانت المقايضة تستحق العناء .. 💯