gpt4 book ai didi

javascript - 构建本地化 react/redux 应用程序的存储

转载 作者:行者123 更新时间:2023-12-01 15:48:04 24 4
gpt4 key购买 nike

我很难在本地化的博客应用程序中构建我的数据。

我的应用程序以三种语言(英语、法语和俄语)显示带有嵌入图片(一对多)的帖子。

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

目前,我的商店结构如下所示:

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

在这个阶段,我的 reducer 并不太臃肿,但我觉得我应该进一步规范化,以便预测何时我将添加与文章相关的标签、作者和其他国际化项目。

所以我正在考虑 (i) 在商店中为语言创建一个额外的字典,(ii) “扁平化”所有其他字典以摆脱“语言环境”子存储键,(iii) 在每个字典中添加一个 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”字典的键的最后一位数字将对应于 locale/language_id,其他数字将对应于项目 id。

我发现当我有一个适用于所有三种语言的商店修改时(例如,如果我删除一篇文章,这篇文章应该全部删除),我会从这种更扁平的结构中受益三种语言,我目前必须在本地化的子词典和所有辅助商店的子词典(例如“editStateOfFieldsOfArticles”(我有一些其他此类辅助词典))上做一个 for...in。

但是,我并不完全确定我是否真的会从进一步扁平化我的哈希中获得任何其他好处(并且 for...in 循环在只管理三种语言的情况下没有那么大的问题——此外,在我的用例中,我需要删除一篇文章并且这个删除需要反射(reflect)在所有三种语言中,我仍然需要遍历三种语言数组以删除扁平文章字典中的三个相应记录)。

另外,我担心性能问题:因为我将把我的整个集合(文章或任何其他国际化项目)存储在相同的平面树下,无论它们涉及哪种语言,我担心对值的访问可能会变慢到更结构化的树,我可以在其中通过“子键控”本地化分支来访问项目——事实上,后端数据库将本地化的文章存储在不同的本地化表中)。

我将非常感谢在为国际化内容构建 Redux 存储或其他具有复杂交叉关系的存储方面有经验的任何人,他们可以就以下方面的自身经验提供一些反馈或建议或提示:
- 代码可读性,特别是在 reducer 和内存选择器中,
- 比较嵌套树与扁平树的性能,
- 进一步规范化与保持“一点”嵌套的总体好处。

最佳答案

这次聚会太晚了,但以防万一你仍然好奇。

我认为你的第一个实现绝对是优越的。对 3 个项目的 for 循环不是一项繁重的交易,您可以(并且应该)将其分解为辅助函数:

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缓存您的查找并制作包含区域设置的可重用查找功能。

关于javascript - 构建本地化 react/redux 应用程序的存储,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34964632/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com