Redux: Cómo inicializar redux con objeto inmutable

Creo que lo que quieres es algo como esto

// 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)

Debería permitir que las tiendas definan su propio estado inicial usando un parámetro predeterminado como @emmenko mostró.

El argumento initialState solo debe usarse para rehidratar el estado del servidor o almacenamiento local. ( @acdlite , es posible que queramos explicar esto en los documentos).

Dicho esto, lo que intentaste debería funcionar. ¿Alguien puede investigar?

No, lo que probé no funciona. Solo quiero crear datos iniciales para todas las tiendas en un solo lugar. Supongo que esto es lo que no debería hacer.

Solo quiero crear datos iniciales para todas las tiendas en un solo lugar. Supongo que esto es lo que no debería hacer.

Tu decides. Me parece mejor dividir los datos iniciales.

Aún así, si algo no funciona, ¿lo dejamos abierto? Volveré a visitar la próxima semana y veré por qué no funcionó.

El problema es con composeStores que asume que el estado raíz es un objeto JS simple y accede a las propiedades con state[key] , que falla con Immutable.Map . Creo que puede funcionar con Immutable.Record ya que eso hace que los campos sean accesibles a través de las propiedades regulares de JS.

Sin embargo, puede haber otros lugares en los que esté asumiendo un objeto simple.

Oh. ¡Esa es una gran captura! Gracias por la explicación. Esto tiene mucho sentido.

El uso de conectores también falla por la misma razón: isPlainObject(Immutable.Record) === false .

@pierregm Esto es realmente correcto. Si extendiera las propiedades del Registro sobre los accesorios del componente, eso no funcionaría de todos modos. Depende de usted escribir select={state => state.get('something').toJS()} .

Pude hacer que funcionara así,

// 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()}
}

Funciona perfectamente, pero acaba volviendo a renderizar todos los elementos de la secuencia (una vista de lista). Me preguntaba cómo se podría implementar algo que compare el estado anterior con el nuevo estado a nivel de tienda e invalide la necesidad de representar cualquier componente allí mismo cuando no hay cambios en los datos. NuclearJS hace esto con estructuras inmutables. ¿Cuál sería la forma recomendada de implementar algo así en redux?

@owais

Consulte Volver a seleccionar: https://github.com/faassen/reselect. Proporciona una funcionalidad similar a los captadores NuclearJS.

@gaearon ¡Genial! Gran charla en ReactEurope ¡Por cierto! Gracias.

Este es mi intento de usar Immutable.js con redux 1.0.0, https://github.com/gajus/redux-immutable

¡Bien @gajus! Probando redux-immutable ahora y realmente me gustó el patrón https://github.com/gajus/canonical-reducer-composition

Gracias @chiplay. Realmente agradecería sus comentarios si encuentra deficiencias o tiene ideas para mejorar.

¿Existe alguna ventaja de usar estructuras inmutables junto con redux? cuando el redux se basa en un comportamiento inmutable (por ejemplo, las tiendas devuelven una nueva copia del estado)? Rendimiento (¿algún punto de referencia?) ¿o algo mas? gracias

@jsifalda

Ventajas de usar Immutable con Redux:

• No puedes mutar por error
• Rendimiento mucho más rápido y mejor consumo de memoria con matrices y objetos grandes

Contras de usar Immutable con Redux:

• Nueva API para aprender para su equipo
• Mayor tamaño del paquete
• Un poco más complicado de depurar

¡La compensación depende de usted!

@gaearon
¡Muchas gracias por una respuesta rápida y útil!

Si desea ImmutableJs y Redux que cumpla con los estándares de Redux, puede echar un vistazo a https://github.com/indexiatech/redux-immutablejs ,

@gaearon ¿Es posible poner un enlace en el sitio web?

Gracias Asaf. Estoy seguro de que la gente lo encontrará útil.

El 4 de septiembre de 2015, a las 18:36, Asaf Shakarchi [email protected] escribió:

Si desea ImmutableJs y Redux que cumpla con los estándares de Redux, puede echar un vistazo a https://github.com/indexiatech/redux-immutablejs ,

@gaearon ¿Es posible poner un enlace en el sitio web?

-
Responda a este correo electrónico directamente o véalo en GitHub.

@asaf

Buenas cosas, ¿te gustaría hacer un PR para Ecosystem.md ?
Con mucho gusto lo agregaré allí si agrega pruebas a su proyecto.

@gaearon Hecho con pruebas unitarias, PR es: https://github.com/rackt/redux/pull/707

¡Gracias!

Hola a todos,
una pequeña pregunta para @gaearon , de las pruebas rápidas que he hecho hasta ahora para implementar ImmutableJS en mi aplicación React / Redux existente, se siente un poco más lento: - / pero tal vez estoy haciendo algo de manera incorrecta ...

Caso de uso básico: obtener una colección de datos de una llamada a la API y almacenarla en un reductor ...

De mi reductor,
Sin ImmutableJS:

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

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

Con 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)
})

Me pregunto si el "tratamiento" que ImmutableJS está haciendo no está costando más aquí.

Por lo que entiendo de la inmutabilidad, el beneficio es mayor cuando el renderizado entra rápidamente, ¿verdad?

Gracias por tus comentarios.

El beneficio es que operar en matrices y objetos grandes cuesta menos memoria y funciona más rápido. No hace una gran diferencia en aplicaciones pequeñas.

OK gracias.
¿Así que tengo el enfoque correcto de todos modos?

Sí, me queda bien.

Hasta ahora, la compensación ha valido la pena .. 💯