@parumenon1 Regarding what you told about POSTs… Now it makes a lot of sense to me. Since it is only a resource we will be accessing all the time, and most of the components are parts of some resource (Eg. data-type components). How about we do the same for GETs as well? As in only the top resource component will be using AJAX. The sub components will be be getting the data from the resource component. What do you think? (This can differ for components like search)
@sunbiz Please correct me if there are different use cases.
This suggestion is for resource components which will be having ten odd data-type components (including the repeated ones). Rather than letting all of them to send GETs and filter them separately, we can send one GET from the resource component and distribute the data among the sub components.
@SuKSW I dont think we can do what you thought. We do POST on bigger element because we barely use POST anytime for just one component. However for displaying existing data we might do GET for eg:Name on different pages. All we have to do is provide URL wherever used which is very easy to add rather than adding ajax response to same component on various pages. We are also trying to make it easy for developer this way. I still prefer to do GET on every small component and POST on pages. That was also the advice given by @sunbiz even in zoom meeting we had, to clear up the confusion regarding this. This way it is useful while building the complete EHR.
I agree with @parumenon1 and this is what we discussed on the call on zoom. The core data type elements (and some other ones that are going to be used often in an EHR) need to be able to do GET, so that they can be used on multiple pages, in different contexts, use-cases and applications. These should be then assembled, and their individual GETs might be disabled and only one main page GET can fill the data into the smaller components. POST should behave similar for required elements, such that they can be used as the smallest unit.
A recent frustrating problem that I discovered is that LitElement doesn’t do two-way binding like the PolymerElement does. This means a lot of goodness of polymer and documentation from their site doesnt work. They state performance reasons to remove two-way binding, which a few other frameworks have also mentioned. This IMO was a killer feature that was removed. @SuKSW are you using PolymerElement or LitElement? Will you send some MR soon, so that I can see that you are going in the right direction?
That’s why I use the term custom elements, when they can be reused, where as I use the term components when they are assembled from custom elements. Off course, this is my own terminology, but I have thought it is a useful way to think about reusable parts of the web platform.
As a solution to work it out without two way binding, I was thinking of passing in a method which can manipulate the parent elements properties. I will inform both of you if it becomes successful. I am using LitElements. I will soon send a MR.
I recommend that you use a property and not a method/event/callback approach. The property approach is sort of translational and easy to figure out for whoever will use the component. Off course polymer does the conversion between property and attribute automagically. Again, I think we already have examples of these in either the mwc-** components or the custom elements that are in your repo.
@parumenon1 I just added a component that can populate the inputs via both an ajax and a json object that can be passed in. This was what I was trying to say.
@SuKSW since we are on evaluation day for GSoC, and you have not sent any merge requests for elements yet, I suggest that you work on Issue #23 and send us an MR on gitlab soon. I would also appreciate if you can create issues in gitlab for any custom elements that you are working on, and send an MR in relation to the issues that you create. Please send the MR in the next couple of days.
@parumenon1, can you also create issues for any custom elements you are working on, send MR against those in the next couple of days.
We would like to do the evaluations on 14th June. We expect to evaluate against what we had discussed on our zoom call that about half of the elements for the FHIR resources that you had selected would be done by each of you.
@sunbiz, @namratanehete, @aethelwulffe, I have sent MR for components I worked on for first evaluation. Most of the work was related to upgrading the components that I made to fix issues that were figured as I kept working and also based on suggestions from @sunbiz. These 14 components I had made relate to three main resources, the Patient, Practitioner and Organisation. Few of them are reusable within these resources, which was the goal of making these components and hence they are not made again. Currently I am working on my 4th resource Location out of the 5 resources I was advised to work as per mentors. I am hoping to complete the resource Location by first evaluation.
The resources I promised to work on initially are Schedule, Appointment, Immunization, MedicalStatement. I have sent MRs for fhir-coding, fhir-codeable-concept. Out of the total of 84 sub fields that belongs to the above four resources, these two can cover upto 27 fields. All the instructions necessary to use the components are added to the readmes. The functionalities were added considering all possible requirements.
I am currently working on the fhir-identifier component which I will submit the MR regardless of the evaluation result. The MR for the Issue#23 have also been sent (I rebased that branched to the upstream master while it was in a pipeline fail, and that is the reason for it to also show red cross in front of it).
@SuKSW, I had to close the MR because it had too many non-related commits. Please squash your commits and have separate feature branch for each issue. Please send a new one, and I am sorry if this causes you to repeat any work or cause any difficulties.
I would like you to tell us the pros and cons of each of the templates. I recommend using PWA starter kit, but it doesnt have to be exactly one of the templates. You can use concepts from each one of the examples.
@sunbiz that’s completely fine. Actually I was having a doubt from the very beginning. When sending a MR for a Element creation (say fhir-codeable-concept where the branch is “codeable-concept”), if it uses a component that has not been merged yet (say fhir-coding where the branch is “coding”), how should I send the MRs? In this case “codeable-concept” is a branch of “coding” not a branch of master. Is it okay to create branches that way and send the same branches for MRs?
@parumenon1 has proposed a new pattern through which to do two-way binding using ES6 style template expressions. I have reviewed it and I think its a good approach. @SuKSW, Can you also please review and comment on the MR. Since this is a major change, I would like to have another person look at it too - https://gitlab.com/librehealth/lh-toolkit-webcomponents/merge_requests/33/diffs
Great work @parumenon1, I have left a few minor comments on the MR. On major question on the pattern - is it required that the <iron-ajax> element is outside the <div>? Can it not be inside the element’s first child <div>? Please update the MR with a new commit with the suggested changes. Please squash the old and the new commit, such that there is only one commit to merge.
@SuKSW, assume that the MR will be merged if you sent it first. So any commits should be in order, assuming that the other branch will be merged in advance. Does that make sense?