[Structure] Structure Update about hms-widget-sdk HOT 1 CLOSED

From your question :

Backend

For clients to render correct data format (SFHIR/HMS Connect), we would like to confirm which approach should be used.
a. Server explicitly inform client. e.g. special HTTP Header
b. Client try to auto-detect the format. e.g. find some unique indicator
Assumption: Client may try to specify required format, but in some situations, the server might not be able to honor the request.

For my opinion:
client should be stateless and server side should handle a little task. So I suggest you to implement middleware for parsing/compiling the data object. The middleware can be implemented in frontend/backend upon your design.

Frontend

For hms-data that have multiple sets, which set of data that we should use for search or display? Such as patient’s names for the SFHIR standard that have 2 sets, Official and Maiden.

Should support both formats

I suggest following the patient-browser for display hms-data.

I'm not sure what patient-browser is...

We will add Typescript for React.

OK krub, please don't forget add some comment in you source code.

We have to add the folder structure.
app/services → a service to fetch data from the server.
app/hooks → sometimes we use a hook to implement a stateful function.

OK krub. If you can design middleware to parse/compile the data object, please attach it into this topic.

Are we understand component structure correct?
/base → as same as components in Material-UI library (Stateless)
such as Button, Grid, Input
/template → many bases combined (Stateless)
such as Searchbar
/widget → many templates combined (Stateful)
such as PatientSearch

OK krub.

from hms-widget-sdk.