All Recordings of meetings are stored in a google folder which can be found here : https://drive.google.com/drive/folders/16YDMfHWiFoUpqu61DQxLk9EnZTHhBKSq?usp=sharing
Agenda for the meeting will include:
-General Config Library
-Config schema for the dashboard
Recommendation: these are schemas that will be interpreted by something, thus the focus should be on building the schema for one usecase for now then build as we go.
How will the frontend know what to display based on the facts that it needs to know? Current its configured to have a context with a user object available to every single module within the SPA.
The big architectural problem that may need to be solved is " will the config as is be built into the frontend and used or is it something that is requested by the frontend by the backend ? do we want data to drive those decisions?
Next steps :
Summary of Next Steps:
Andre from Mekom solutions joins the MF squad
Summary of Next Steps
Agenda for the Meeting:
Action Items for the Next Meeting:
The focus of the call will be to shift to work mode and begin actual development work.
Agenda for the call will be
I published all our frontend code to npm. See https://www.npmjs.com/search?q=%40openmrs%2Fesm
- I renamed the in-browser js modules from @openmrs/name to @openmrs/esm-name to match the repo’s name.
- The styleguide documentation website is now hosted at https://styleguide.openmrs.org
- I created a PR that adds a primary-navigation and patient-dashboard applications. Please review it at https://github.com/openmrs/openmrs-esm-root-config/pull/16
- I created a PR that starts migrating esm-login to use the styleguide. Please review it at https://github.com/openmrs/openmrs-esm-login/pull/7
- I created a new import map for openmrs-spa.org. The hackathon one still exists in Digital Ocean but is no longer used.
- I created Github releases and release notes for each of the published packages. Example at https://github.com/openmrs/openmrs-esm-styleguide/releases
- I published browserslist-config-openmrs. More details at https://github.com/openmrs/browserslist-config-openmrs about what that is
- I installed fork-ts-checker-webpack-plugin in each of our typescript projects, which will surface typescript errors earlier on before you try to commit.
Questions were raised on how best to bundle and package the work that has been done so far as well as how to replicate on a local server.?
This style guide ,(JS file ) is made available through the index.html file. So these are global styles that are available to any module within the project.
Process creating or making addition to the Style Guide:
If you do face some bottlenecks:
you can override your CSS, you can write your own CSS for your code. Other options for overriding One of them is simply don't use the CSS class that is in the style guide and use your own CSS class.
The other one is use the CSS class in the style guide, but then add your own CSS class that adds or modifies some of the CSS properties.
And using specific CSS selectors, or even exclamation point important within your CSS to make sure that it overrides what's in the style guide.
The third option is if you really don't like what's in the style guide a lot, then you can override the entire style guide module itself and use one that you maintain
Maybe beyond overriding colors, for instance, because that's something people think of often
Just for simplicity. Right now, the colors which are being used are purely functional like there's an interaction color which is blue, and there’s an alert color red, green success color. There's no brand colors anywhere currently in the style guide.
At a later date when there are more functionalities it may be possible to make edits in one area, which cascade through the whole UI. This is not being covered at this time.
UX/UI work for the week
This was presented for discussion and review.This page is going to basically show up as the primary page just like everybody else has opened Mrs implementation does right now. It will take the Username and password and send a request to session API to authenticate.
Entering the “Location” will be discussed at a later date.
Process for Application development:
Initial tickets will be created to define what needs to be done. These can be modified as necessary.
After a PR is done, the creator of the PR will assign it to a squad member within 24 hours. The squad member will then have 1 week to provide feedback or approve the PR.
Dev Side project management will be monitored through the JIRA Board https://issues.openmrs.org/projects/MF/summary
Process for developing the design and approval to start coding:
Figma tutorials: Greg has been asked to develop Figma tutorials for the developers.
Planning for the following week:
The below gif is the Ampath application running as a single microfrontend. The plan is to use the strangler pattern 2 to replace parts of the application with openmrs core microfrontends (in collaboration with the entire OpenMRS community). @fali will likely be creating an RFC proposal in the coming weeks to go into more depth about what migration looks like for an existing SPA to microfrontends.