Web Components Brainstorming

toolkit
gsoc2018-project
gsoc2018

(Tendonge Ryan) #1

@gsoc2018students @sunbiz This thread concerns all students who would be developing or working with web components over the course of gsoc 2018. There are a number of ways for developing angular components from scratch, for example using the yeoman generator. The aim of this thread is to ensure uniformity, adopting common practices so that we have a uniform looking product at the end, because although we all work on different projects, we still work under one organization, LibreHealth. This was suggested by @judywawira


(Saptarshi Purkayastha) #2

I think this is a great idea. @SuKSW, @parumenon1 are the others who should be linked to this thread. But I also believe that the best way to work on webcomponents, is not to depend on a framework. Using libraries is a good idea, but depending on a framework involved learning curve, dependence on maintenance and backward compatibility of the frameworks.

Polymer is a lightweight framework, that can be used just like a library, using the web standards around webcomponents. So, that is my recommendation. There are a bunch of others, but we should use this thread for both the frameworks/library… but also the design language, style and color scheme. Please everyone discuss, if you have ideas,


(Ivange Larry) #3

@tenas97 I second @sunbiz on not using a framework for this. A framework affects the entire application stack and takes over the architecture. This will make component reusability hard. For example web components built with Angular can only be used within Angular projects. It’s best to have these components independent of any framework and the apps that later use these components can then use which every framework they want.


(Subhashinie) #4

Hi @tenas97, myself and @parumenon1 are supposed to create a set of web components based on FHIR resources. https://github.com/namratanehete/librehealth-signin is a web component (built using Polymer) that was given to us as an example. We are currently picking up each FHIR resource and trying to figure out how they can be broken into components. This is our project discussion thread.


(Saptarshi Purkayastha) #5

I don’t believe that is the most up-to-date example. the one below is a more updated polymer example. https://github.com/parumenon1/lhtoolkit-core


(Ivange Larry) #6

@sunbiz I was also thinking of how these components will be distributed. Do we have a LH components library repo where everyone can add a new component by making a PR and projects that need these components can just use this library. Or does every project just build the components in their own separate project, like components for radiology will live in lh-radiology-owa, components for toolkit will live some where else, etc.


(Saptarshi Purkayastha) #7

@ivange94 IMO, we should not build a new infrastructure for distributing webcomponents. Instead, bower.json from github/gitlab or the NPM registry should be used for any new components that we release. We can standardize the documentation, so that all the README.MD provide API documentation and a demo for the webcomponent, but we shouldn’t build our own custom gallery.


(Robby O'Connor) #8

@sunbiz https://bower.io/blog/2017/how-to-migrate-away-from-bower/

How to migrate away: https://bower.io/blog/2017/how-to-drop-bower-support/


(Saptarshi Purkayastha) #10

Sure, Yarn is a great alternative. My point is we should use one of these instead of building our own custom gallery.


(Robby O'Connor) #11

It was more for a point of information – but I agree – OpenMRS went hogwild and I’m not in favor of exploding our infra for no gain whatsoever. We can use bintray, or npm to host our packages.


(Ivange Larry) #12

I think this is a good idea.