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.
Link to the element : https://gitlab.com/SuKSW/lh-toolkit-webcomponents/blob/newcomponent/packages/fhir-coding/fhir-coding.js
Link to the demo : https://gitlab.com/SuKSW/lh-toolkit-webcomponents/blob/newcomponent/demos/fhir-coding.html
Hope the comments are helpful.
@sunbiz I’ll use a property approach to solve it. Thanks. I understand.
@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.
I started working on Issue #23. Also created issues for the custom elements I am currently working on. I will send the MRs in the next couple of days.
@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).
@sunbiz, @namratanehete, @judywawira, As first evaluations are over and this is time when @sunbiz had told me to start assembling the components, shall I go ahead and assemble them using progressive web app? https://github.com/Polymer/pwa-starter-kit Any suggestions on this are most welcome.
I vote yes too… sorry for the delayed response.
@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.
Use polymer progressive web app? which do you think would be better out of the four templates?
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?
Currently I have four components which includes the previous component, and has a chain like dependency.
Coding --> CodeableConcept --> Identifier --> Reference
Following are the specifications I’ve been using,
@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?
@sunbiz I will make the changes you have commented in MR. I will also check the functionality of components putting the ajax in div and get back on it.
@sunbiz I am going through her code. The new pattern looks good! @parumenon1 You have spent a lot of effort. One quick question, why did you change your show hide fields from Boolean to string? Regarding all other changes, I’ll make sure to include them in my components as well (will include them in the new MRs of the old components as well). Good job @parumenon1!
@sunbiz having the commits in order, assuming that the other branch will be merged in advance makes sense. I’ll send them including the new changes as well.
@SuKSW. That was a major change which i addressed today in my blog post. Properties being ‘Boolean’ was made with intention to show or remove the field just by declaring true or false. But this had one major drawback. Boolean values set to true if that property/attribute is displayed and doesn’t change to false on declaring it as false. In case the attribute is not displayed it can be set to true y declaring true. It just works one way and not both ways and hence we change it to string. By doing this, we can choose to remove a field that is displayed by passing property as false. The description for this pattern of code is blogged at https://email@example.com/an-efficient-pattern-for-components-using-litelements-bb187a6602be With my previous pattern property true in constructor and being declared false in component dint work for removing.
Totally missed it. I’ll correct my components and improve the unit tests as well. Thanks