[x] This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
[ ] My work includes tests or is validated by existing tests.
Summary
Storing the Concept object in OHRIFormfield, in order to reduce the db calls to fetch concept information whenever needed.
Ways for Storing the Concept Object:
Option 1: Modify "concept" field: Change the type of the "concept" field from a string to an object (or allow it to hold both strings and objects). This approach directly replaces the existing concept storage mechanism.
Option 2: Add new "meta" property: Introduce a new property named "meta" (type: Record<string, any>) within the data structure. This "meta" property would act as a dictionary to store additional information, including the full concept object under a specific key.
Preferred: Adding a new "meta" property seems like a more suitable approach for the following reasons:
Backward Compatibility: It maintains compatibility with existing code that uses the "concept" field for concept UUIDs or mappings.
Flexibility: The "meta" property can be used to store other relevant information about the question beyond just the concept object.
Clarity: It keeps the core data structure cleaner by separating the concept object from core question properties like label and type.
As mentioned in the ticketO3-2167, the fetch call can be reduced, if we store the full concept object, and we can avoid the unnecessary fetch call here
added meta property in the OHRIFormField interface, described here: esm-form-engine-lib PR
Requirements
Summary
Storing the Concept object in OHRIFormfield, in order to reduce the db calls to fetch concept information whenever needed.
Ways for Storing the Concept Object:
Option 1: Modify "concept" field: Change the type of the "concept" field from a string to an object (or allow it to hold both strings and objects). This approach directly replaces the existing concept storage mechanism.
Option 2: Add new "meta" property: Introduce a new property named "meta" (type: Record<string, any>) within the data structure. This "meta" property would act as a dictionary to store additional information, including the full concept object under a specific key.
Preferred: Adding a new "meta" property seems like a more suitable approach for the following reasons: Backward Compatibility: It maintains compatibility with existing code that uses the "concept" field for concept UUIDs or mappings. Flexibility: The "meta" property can be used to store other relevant information about the question beyond just the concept object. Clarity: It keeps the core data structure cleaner by separating the concept object from core question properties like label and type.
As mentioned in the ticketO3-2167, the fetch call can be reduced, if we store the full concept object, and we can avoid the unnecessary fetch call here
added meta property in the OHRIFormField interface, described here: esm-form-engine-lib PR
Screenshots
Screen-Recorder
Related Issue
O3-2167