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


Reply via email to