Project: Web Component-based Drag-and-Drop Form Designer for LibreHealth Toolkit

Projects Toolkit
, , ,
1

Hi @Sujal_Co,

Congratulations on being selected for GSoC 2026! Use this topic for all communications this summer. No private messages should happen. Use the Jitsi link below if you need to have real-time discussions with your mentors.

1 Like
Congratulations to our 4 Accepted Contributors for GSoC 2026 and Next Steps
Librehealth Chat is back
3

Thank you @r0bby and @sunbiz! I am ready to begin the community bonding period. @sunbiz, I would like to schedule a call to discuss the architecture decisions, JSON schema format, and FHIR binding approach. Please let me know your availability. I will also post a detailed week-by-week project plan in this thread shortly. Thanks :slight_smile:

1 Like
4

Hi @sunbiz, I was going through lh-toolkit-webcomponents and I think my form designer should go as a new package inside packages/ like how fhir-vitals and fhir-period are there. I couldn’t find any separate lh-toolkit-form-entry repo so I’m assuming that’s the right place. Just wanted to confirm before I go deeper and also should I work on master directly or create a separate branch?

5

Hi @sunbiz, sharing my community bonding plan and a couple of questions before coding starts

I Went through lh-toolkit-webcomponents understood the monorepo structure under packages/, LitElement-based components, and how FHIR resources are bound as element properties,

Explored drag-and-drop approaches — leaning toward SortableJS over native HTML5 DnD for better touch support

My plan for the remaining bonding period (until May 24):

  • Finalize where the form designer package should live (new package inside lh-toolkit-webcomponents vs. separate repo)

  • Draft the JSON schema structure for the form definition

  • Set up project scaffolding and make a small exploratory commit

Two questions I need your input on:

My May 5 message asked about repo location, should the form designer go as a new package inside packages/ in lh-toolkit-webcomponents, or as a separate repo?

And @sunbiz please correct me if i am wrong, For midterm evaluation, I’m planning to have a working drag-drop canvas with field palette and JSON export by then. Does that match your expectation?

Available for a Jitsi call or happy to continue on Rocket.Chat, whatever works for you.

6

I also re-read the original project discussion thread from March where @parumenon1 suggested using Lit for the designer shell and starting with component-registry.json. My plan aligns with that, using LitElement for the Canvas, Palette, Properties Panel, and DataBinder components, with component-registry.json as the component registry. My main open question is still the repo location, and whether to use a Lit Reactive Controller for FHIR data binding.

7

Thanks for the detailed write-up. Sounds like you’ve got a solid handle on the codebase. Understanding the monorepo layout and how FHIR resources bind to component properties is exactly the grounding that pays off later.

On SortableJS vs. native HTML5 DnD: agreed, SortableJS is the safer call. Touch support and consistent cross-browser behavior matter more here than shaving a dependency.

On repo location: rather than a brand-new package or a separate repo, take a look at the react-ehr branch: https://gitlab.com/librehealth/toolkit/lh-toolkit-webcomponents/-/tree/react-ehr, which demonstrates the components in use. A dedicated branch for the form designer following that same pattern might be the cleanest path: you stay close to the components, can iterate freely without disturbing main, and we can have CI generate the publishable packages from that branch. Could you look at how react-ehr is set up and let me know if that approach works for the designer? If a branch turns out to be awkward, a new package under packages/ is the fallback.

Your remaining bonding-period plan looks right. Finalizing where the designer lives, drafting the JSON schema, and a small scaffolding commit is good scope for the time left.

For midterm, a working drag-drop canvas with a field palette and JSON export is a reasonable target. One suggestion: let’s review the JSON export schema together before you build much on top of it. It’s the contract the rest of the tool depends on, so it’s worth getting an early look. @parumenon1 anything you’d add or reprioritize there?

Looking forward to the exploratory commit.

8

Hi @Sujal_Co Firstly congratulations on being selected. And great to see the thoughtful preparation going into the bonding period.

I agree with @sunbiz on the dedicated branch approach and midterm scope. On the Lit Reactive Controller for FHIR binding - the react-ehr branch uses Redux for state management since it’s a React app, so I think there’s no existing precedent in the repo for this pattern. Since the form designer will be LitElement-based, a Reactive Controller seems like a natural fit for encapsulating FHIR fetch/update logic, but wanted to check with you before Sujal goes down that path. What do you think? @sunbiz

9

Hi @sunbiz and @parumenon1, thank you both for the detailed guidance this really helps clarify the path forward.

I’ll study the react-ehr branch more closely and treat that as the reference for how the designer branch should be structured. I also understand that the JSON export schema should be reviewed together early, so I’ll draft a first version and share it here before building too much on top of it.

For the FHIR binding approach, I’ll wait for your suggestion before committing to a pattern. Since the project is Lit-based, a Reactive Controller does sound like a good fit, but I agree it’s better to confirm the direction first.

I’m also going through the OpenMRS O3 demo to better understand the real workflow context. My goal for the remaining bonding period is to finish the branch setup, share the schema draft, and make a small exploratory commit.

Thanks again, I’ll keep you updated here.