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