medblocks / medblocks-ui

Web Components Library for Medblocks Ecosystem
https://www.npmjs.com/package/medblocks-ui
Apache License 2.0
54 stars 15 forks source link

Missing RM-Mappings support #56

Open owenfar opened 7 months ago

owenfar commented 7 months ago

Hello,

Currently the library does not support some RM types such as DV_IDENTIFIER, DV_URI, SECTION, ... I don't know if I'll face more clashes but I'm wondering if the library is being maintained / up-to-date with latest changes in data types found in EHR templates & archetypes?

Another thing I want to point out is multi-lingual support. Templates can be exported in multiple language types, currently I think the library only defaults to EN (at least from the VSCode extension side of things).

Thanks in advance

sidharthramesh commented 7 months ago

Hey @owenfar, it is true that we currently don't support all DV types - DV_IDENTIFIER and DV_URI included. However, you can use <mb-context> or <mb-input> along with these RM types in most cases depending on your use case - all of the rest of the form components will still work.

Regarding SECTION - it's more of a structural data structure, with usually leaf nodes underneath. Medblocks UI does not deal with such RM types. We only deal with the end-left input nodes.

Regarding multi-lingual support - since the output artefact of Medblocks UI is a set of web components with predefined labels, it would be challenging to add multiple languages to the workflow, without <mb-form> depending on the web template. However, if you can directly take the labels from the web template, then I think you should be able to use an i18n library and dynamically pull the labels based on the language selected. I would like to hear ideas on other way we could support this multilingual workflow.

Medblocks UI is still maintained, and we provide regular updates based on the needs of our users. Happy to see you're considering this 😄. Any input or feedback is appreciated!

owenfar commented 7 months ago

Hello @sidharthramesh, thank you for your reply. I'm glad to hear it's still maintained because it's the best library available at the moment and we're considering to use it in production in the near future.

Do you see DV_IDENTIFIER more as an <mb-context> from your point of view? I checked the docs here and I'm not sure whether I need an input for the ID, but some templates do seem to request the ID to be submitted although it's not very clear.

For DV_URI and DV_EHR_URI I used the <mb-input>. And for SECTION, I'm guessing I can leave it empty then :)

Thanks once again for these suggestions.

In terms of languages, for our use-case I updated the transformations object functions to include a second parameter called lang example:

DV_COUNT: (n, lang) => [
    {
        name: 'Count',
        html: `<mb-count path="${n.path}" label="${(n.localizedNames) ? n.localizedNames[lang] || n.name || '' : n.name || ''}"></mb-count>`,
     },
],

This way if the language is available, we can output the right language context.