It absolutely makes sense and it's actually even closer to what we did than my previous solution.
Glad you liked the idea. --- Andrea Brancatelli On 2020-09-03 10:59, Olaf Krueger wrote: > Hi Andrea, > > in order to handle enums, I end up with a variant of your solution: > I rather would like to keep the translation separated from the enum > implementation. > So I moved the translation responsability to whatever i18n solution, e.g. > https://www.i18next.com. > One benefit is that all translations are at the same place and we don't need > to duplicate same translations for same enumeral values across other enums. > > Moreover, I decided to store each single enumeral of an enumeration in its > own document. > A namespace could be used if needed: > { > _id: "issue.status.closed", > docType: "enumeral", > namespace: "common" > value: "closed" > } > > { > _id: "issue.status.open", > docType: "enumeral", > namespace: "common" > value: "open" > } > > In order to fetch all enumerals of an enumeration we just have to query the > _all_docs view by using a proper start- and end key. > > The enumeral document is nested within the parent: > { > _id: "issue.23423", > title: "How to handle enums", > status: { > _id: "issue.status.open", > docType: "enumeral", > namespace: "common" > value: "open" > } > } > > Then, at presentation level, I am am going to use a i18n solution in order to > map the enumeral value with its associated text/translation. > E.g.: > text = i18next.t(doc.status.namespace + ':' + doc.staus.value); > > Hope that makes sense! ;-) > Maybe it's helpful for others. > > Thanks, > Olaf
