javascript - paginas - react helmet ssr

Estructurar la tienda de una aplicación de react/redux localizada

Question

Me está costando estructurar mis datos en una aplicación de blog localizada.

Mi aplicación muestra publicaciones, con imágenes incrustadas (uno a muchos), en tres idiomas (inglés, francés y ruso).

El visitante puede elegir su ubicación. Los editores pueden editar las versiones localizadas de sus publicaciones en los tres idiomas.

Por el momento, la estructura de mi tienda se ve así:

{ articles:
  {
    en: {
      1: { id: 1, title: "my first title", body: "my first body", picture_ids: [1, 2, 3]},
      2: { id: 2, title: "my second title", body: "my second body", picture_ids: [1, 4, 5]},
      3: { id: 3, title: "my third title", body: "my third body", picture_ids: [6, 7, 8]},
      ...
    },
    fr: {
      1: { id: 1, title: "mon premier titre", body: "mon premier corps de texte", picture_ids: [1, 2, 3]},
      2: { id: 2, title: "mon second titre", body: "mon second corps de texte", picture_ids: [1, 4, 5]},
      3: { id: 3, title: "mon troisième titre", body: "mon troisième corps de texte", picture_ids: [6, 7, 8]},
      ...
    }
  },
  pictures:
   {
      en: {
        1: { id: 1, title: "My great picture", url: "http://..."},
        2: { id: 2, title: "My other great picture", url: "http://..."},
        3: { id: 3, title: "My not so great picture", url: "http://..."},
        ...
      },
      fr: {
        1: { id: 1, title: "Ma superbe photo", url: "http://..."},
        2: { id: 2, title: "Mon autre superbe photo", url: "http://..."},
        3: { id: 3, title: "Ma photo pas vraiment superbe", url: "http://..."},
        ...
      }
   },
   editStateOfFieldsOfArticles:
   {
      en: {
        1: { title: true, body: false },
        2: { title: false, body: true },
        3: { title: false, body: false },
        ...
      },
      fr: {
        1: { title: false, body: false },
        2: { title: false, body: false },
        3: { title: true, body: true },
        ...
      }
   }
}

En esta etapa, mis reductores no están demasiado hinchados, pero tengo la sensación de que debería normalizarme aún más para anticipar cuándo voy a agregar etiquetas, autores y otros artículos internacionalizados en relación con los artículos.

Así que estoy considerando (i) crear un diccionario adicional en la tienda para los idiomas, (ii) "aplanar" todos los otros diccionarios para deshacerme de las claves de substore "locale", (iii) agregar un campo language_id en cada uno de los elementos almacenados en los otros diccionarios y (iv) modificar las claves numéricas en cada uno de mis diccionarios como claves compuestas. Esto se vería así:

{languages:
  {
    1: {id: 1, locale: "en", long: "English"},
    2: {id: 2, locale: "fr", long: "Français"},
    3: {id: 3, locale: "ru", long: "русская"}
  }
  articles:
  {
    11: {id: 1, title: "my first title", body: "my first body", picture_ids: [1, 2, 3], language_id: 1},
    21: {id: 2, title: "my second title", body: "my second body", picture_ids: [1, 4, 5], language_id: 1},
    31: {id: 3, title: "my third title", body: "my third body", picture_ids: [6, 7, 8], language_id: 1},
    42: {id: 1, title: "mon premier titre", body: "mon premier corps de texte", picture_ids: [1, 2, 3], language_id: 2},
    52: {id: 2, title: "mon second titre", body: "mon second corps de texte", picture_ids: [1, 4, 5], language_id: 2},
    62: {id: 3, title: "mon troisième titre", body: "mon troisième corps de texte", picture_ids: [6, 7, 8], language_id: 2},
    ...
  },
  pictures:
  {
    11: {id: 1, title: "My great picture", url: "http://...", language_id: 1},
    21: {id: 2, title: "My other great picture", url: "http://...", language_id: 1},
    31: {id: 3, title: "My not so great picture", url: "http://...", language_id: 1},
    12: {id: 1, title: "Ma superbe photo", url: "http://...", language_id: 2},
    22: {id: 2, title: "Mon autre superbe photo", url: "http://...", language_id: 2},
    32: {id: 3, title: "Ma photo pas vraiment superbe", url: "http://...", language_id: 2},
    ...
  },
  editStateOfFieldsOfArticles:
  }
    11: {title: true, body: false, language_id: 1},
    21: {title: false, body: true, language_id: 1},
    31: {title: false, body: false, language_id: 1},
    12: {title: false, body: false, language_id: 2},
    22: {title: false, body: false, language_id: 2},
    32: {title: true, body: true, language_id: 2},
    ...
  }
}

El último dígito de las teclas de los diccionarios "articles", "pictures" y "editStatesOfFieldsOfArticles" correspondería a la configuración regional / language_id y los otros dígitos corresponderían a la id del elemento.

Veo que me beneficiaría de una estructura tan plana al eliminar la necesidad de repetir los idiomas cuando tengo una modificación de la tienda que se aplica a los tres idiomas (por ejemplo, si elimino un artículo, el artículo debería eliminarse en todos tres idiomas y actualmente tengo que hacer un ... en los diccionarios secundarios localizados y en todos los diccionarios secundarios de la tienda (como "editStateOfFieldsOfArticles" (tengo un puñado de otros diccionarios auxiliares de este tipo)).

Sin embargo, no estoy completamente seguro de que realmente tomaría otros beneficios al aplanar más mi hash (y los bucles for ... in no son tan problemáticos con solo tres idiomas para administrar, además, en mi caso de uso donde Necesito eliminar un artículo y esta eliminación debe reflejarse en los tres idiomas, aún tendría que iterar sobre la matriz de tres idiomas para eliminar los tres registros correspondientes en el diccionario de artículos aplanado.

Además, me preocupan los problemas de rendimiento: dado que almacenaré todas mis colecciones (de artículos u otros artículos internacionalizados) bajo los mismos árboles planos, sea cual sea el idioma con el que se relacionan, me temo que el acceso a los valores podría ralentizarse en comparación a un árbol más estructurado en el que puedo acceder a los elementos mediante "subdivisión" en las ramas localizadas; y, de hecho, la base de datos del servidor almacena los artículos localizados en distintas tablas localizadas).

Agradecería a cualquier persona con experiencia en la estructuración de tiendas Redux por contenido internacionalizado u otras tiendas con relaciones cruzadas complejas que pudieran proporcionar algunos comentarios o consejos sobre su propia experiencia con respecto a: - legibilidad del código, en particular en los reductores y en los selectores memorables, - compararon el rendimiento de árboles anidados versus árboles planos, - los beneficios generales de una mayor normalización vs. mantener un "bit" de anidación.

Answer 1

Súper tarde para esta fiesta, pero en caso de que todavía sientas curiosidad.

Creo que su primera implementación es definitivamente superior. Un bucle de más de 3 elementos no es una transacción impositiva, y usted puede (y debe) tenerlo en cuenta en una función auxiliar:

var forEachLanguage = function(state, dataType, callback){
    var languages_data = state[dataType];
    for(language_index in languages_data){
        var data = languages_data[language_index];
        callback(data);
    }
}

//Example for deleting item 2 from articles
forEachLanguage(state, ''articles'', function(data){
    delete data[2];
});

Además, si le preocupa que las búsquedas repetidas sean innecesariamente costosas (aunque de manera realista, no veo que esto sea un problema), puede usar Volver a seleccionar para almacenar en caché sus búsquedas y realizar funciones de búsqueda reutilizables que incorporen la configuración regional.