Can I request you to follow the convention that is in the lh-toolkit-webcomponents branch? Please look at the merge that I did from @parumenon1 where she is using mwc-textfield without any issues.
Also, I changed the build tool a little, since it is inefficient to have to go to each package folder and having to run npm install in it. So, I have added a lerna script to use yarn as the default npm client. So, you will need to install yarn too. All the details are in README.
@sunbiz Regarding the coding convention, I almost duplicated the component fhir-period exactly as it was 
, an changed the functionality while changing fhir-period to fhir-coding. Hope the component I bulit is according to the coding convention.
Regarding mwc-textfield, as I noticed, @parumenon1 has not yet started to work on taking inputs from the user. When I asked her last week she told that will be working on the POST requests starting this week. @parumenon1 If you have already a component that takes input from the user and posts it to the FHIR server, could you give me a link to it?
I’ll change my “inputs” too to “mwc-textfields” and continue working on, adding GET request response data into those fields as well. So later we can add the POST functionality to those components as well.
Thanks you. We’'ll follow the instructions in the README contributing guide.
The unit tests are taking value from the <mwc-textfield>. Please use the “value” property, just like you can from the <input>.
I checked her test code. She uses a “text-fixture” element. Within the test() function she have something like this:
var name = fixture('DefaultElemnt');
Then when adding the event listener to “name”,
var firstName = name.shadowRoot.querySelector('.fName').value;
Therefore I tried accessing value with
document.getElementById("class-of-the-textfield").value
document.getElementById("text-field").value //id used for the input inside textfield
document.querySelector('element-name').shadowRoot.querySelector('.class-of-textfield').value
document.querySelector('.class-of-textfield').value
document.querySelector('element-name').shadowRoot.querySelector('mwc-textfield').shadowRoot.querySelector('.class-of-textfield').value
that did not work either. @parumenon1 tell me when you find a solution.
I am on it this week. Will put it up as soon as I finish one. As of now, I dont have an example. I was working to get all my components into the repo until yesterday. But I think the POST part comes up on the whole page and not a component. Page refers to assembling components I suppose, which I was supposed to start working after first evaluations. So, I think you can go ahead and do GET for your components just like I did and put POST aside for now as its part of Bigger components/page. Pls correct me if I am wrong @sunbiz
Eureka!!! The value can be accessed like this : e.target._input.value. This is how it works :
<mwc-textfield on-input=${e => this.inputValue2 = e.target._input.value}></mwc-textfield>
Found it here: https://github.com/material-components/material-components-web-components/issues/48
It was not the POST I was worried about. I couldn’t take inputs from the granular components to the top level ones. The ones who are writing mwc-testfield are also trying to give a better solution. However… problem solved.
@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.
This resolved the doubt I had in mind.
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.
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.