构建本地化反应/还原应用程序的商店

Question

我在本地化的博客应用程序中遇到困难时期的数据结构。

我的应用程序以三种语言（英语，法语和俄语）显示嵌入图片（一对多）的帖子。

访问者可以选择其语言环境。编辑人员可以用三种语言编辑他们的帖子的本地化版本。

目前，我店的结构是这样的：

{ 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 }, 
     ... 
     } 
    } 
} 

在这个阶段，我的减速器是不是太臃肿，但我有，我应该为了进一步规范了感觉，当我预测我要添加标签，作者和其他国际化项目与文章的关系。所以我正在考虑（一）在商店里为语言创建一个额外的字典，（二）“扁平化”所有其他字典，摆脱“语言环境”子代键，（三）添加一个language_id字段在存储在其他字典中的每个项目中，并且（iv）将我的每个字典中的数字键修改为组合键。这应该是这样的：

{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}, 
    ... 
    } 
} 

“公司章程”的键的最后一个数字，“图片”和“editStatesOfFieldsOfArticles”字典将对应于区域/ LANGUAGE_ID和其他数字将对应于项目ID 。

我看到，当我有适用于所有三种语言的商店修改时，通过摆脱对语言进行迭代的需要，我将受益于这样一种更平坦的结构（例如，如果删除了文章，文章应该在所有三种语言中删除，我现在必须为本地化的子词典和所有附属商店的子词典（例如“editStateOfFieldsOfArticles”（我有一些其他这样的辅助词典）

但是，我并不完全确定，我真的会采取任何其他的好处，进一步扁平化我的哈希（和for ...循环是没有问题，只有三种语言管理 - 此外，在我的用例，我需要删除一篇文章和这个删除需要反映在所有三种语言中，我仍然需要遍历三种语言数组以删除扁平文章词典中的三个对应记录。

另外，我关心的是性能问题：因为我将把我的整个集合（文章或任何其他国际化项目）存储在相同的扁平树下，无论它们涉及哪种语言，我担心访问值相比于更结构化的树，我可以通过在本地化分支中“sub-keying”来访问项目 - 事实上，后端数据库将本地化的项目存储在不同的本地化表格中）。

我会很感激与结构Redux的商店国际化的内容或其他商店复杂的交叉关系，谁可以提供一些反馈意见或有关其自己的经验建议或提示经验的人： - 代码的可读性，尤其是在减速器和备忘录选择器中， - 嵌套树木与平坦树木的比较性能， - 进一步正常化与保持“嵌套”的“位”的总体益处。

Answer 1

超级迟到这次派对，但如果你仍然好奇。

我认为你的第一个实现绝对是优越的。 for循环超过3项是不是征税的交易，你可以（也应该）因素是出到一个辅助功能：

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]; 
}); 

此外，如果你担心重复查找变得不必要昂贵的（尽管实际上，我没有看到这是一个问题），您可以使用Reselect来缓存查找并制作包含语言环境的可重用查找函数。