Hello folks! Another week done and another batch of code written and merged !! In the coming sections I will be explaining the details of the work done this week.
In the previous week, I had implemented the checkin workflow in the react application. According to my plan in the proposal, this week was to be used to create components for the resources that will be used in the Appointment workflow.
the resources are:
In the beginning of the week, I started looking into the
lit: upon which the components are based. I read the documentation and decided how to create the components so that they can be utilised for different CRUD operations.
I also noticed a few bugs in the components while implementing the checkin workflow, for this I created a MR and fixed them :
- https://gitlab.com/librehealth/toolkit/lh-toolkit-webcomponents/-/blob/master/packages/fhir-active-status/fhir-active-status.js#L65 => the value property doesn’t exist on target in this case
- https://gitlab.com/librehealth/toolkit/lh-toolkit-webcomponents/-/blob/master/packages/fhir-decease-status/fhir-decease-status.js#L63 : the value property doesn’t exist on target in this case
- https://gitlab.com/librehealth/toolkit/lh-toolkit-webcomponents/-/blob/master/packages/fhir-human-address/fhir-human-address.js#L94: the value needs to have a fallback, if text is undefined the component will display undefined
- https://gitlab.com/librehealth/toolkit/lh-toolkit-webcomponents/-/blob/master/packages/fhir-human-relation/fhir-human-relation.js#L81: on change doesn’t do expected task
By wednesday I started creating the components. Most of these components have a
codeable-concept property datatype, hence creation of components that can be used in different contexts to implement the mentioned datatypes will help a lot.
By the end of wednesday I had created these datatype components :
Once these components were created, the resource components were not difficult to develop. By thursday I had created Slot-Schedule and by friday Appointment.
During this period my mentor noticed a few bugs in the project:
- inconsistent label case use
- unavailable demo files (build issue)
So along with the development of the components, I made a couple of commits for these issues as well.
As a component will be used for CREATE / GET / PUT request , I made it compatible with everything.
For the create part, inside the constructor an initial empty skeleton value was provided. This value property would be overwritten if the component contains the value attribute. Hence this supports both the cases of create and get operations as a user can avoid the value attribute if the intention is to use the component for creating entries and provide a value after fetching a specific endpoint if the intent is to show entries.
Moreover even if a value property is provided and some of the keys are missing, the component will still remain the same as I have done a check for individual property existence and default value allocation as well, this feature will be helpful for the edit operation.
here is the default value property set inside the Appointment component constructor. Similar structure is used in the other 2 components.
here are the screenshots of the implemented components:
- write unit test for the components.
thanks for reading till the end ❤️ , see you next week 😄