(feat) support for reusable form components #126
Conversation
|
Size Change: +344 B (0%) Total Size: 646 kB ℹ️ View Unchanged
|
pirupius
force-pushed
the
feat/support-reusable-components
branch
from
1a59469 to
cdafd1b
Compare
|
This is very interesting, thanks for this draft PR @pirupius. Quick question, sorry if it should be obvious: What's the main difference between a Sub-Form and a Component Form? Is a Component Form specific to a situation where one is embedding a component/mini-app into a bigger form? So unlike a Sub-Form, a Component also brings it's own special functionality, as well as it's own "form" content with it? CCing @mseaton and @mogoodrich as I believe they've been really interested in embedded components in O3 Forms. |
pirupius
changed the title
@gracepotma Some parts of this are true and others are a little interchanged. Sub-Form: Sub Forms are what is already available with a user able to reference another form. The referenced sub-form is then automatically inserted by the engine and runtime bringing with it any special functionality the subform might have as well content it has as a whole. Form Components: This on the other hand is a feature that the angular form engine (AFE component docs) supported and with this, the person building a form had the power to reuse either part of a component or all sections of a component. For example if you had a form for Antenatal, you could decide to use only a particular section or questions of the Both features are built with reuse in mind. But differ in the way they're created, referenced and use cases. |
There was a problem hiding this comment.
Thanks for working on this @pirupius; however, I have one concern. We seem to be duplicating efforts, especially in this specific task.
A backend module (currently bundled within the refapp) was introduced by @ibacher which defers most build tasks to the backend. This dramatically improves performance for big forms and I believe we should refactor the library to leverage this feature. This module offers the following:
- All referenced forms loaded into the appropriate parts of the main form
- All translations provided in a translation file for the appropriate locale
- Metadata about concepts used in the forms
@kajambiya - This module also plays a role tagential to i18n making life easy to go about adding support for internationalization.
@eudson @kajambiya @pirupius @ibacher what do you think about adding support for "subforms" to this backend module and we get rid of the inbuilt form loader from the library?
@samuelmale I think this is a nice module. Going to check it out especially in implementing form translations. The idea of using the module to load sub forms also sounds good especially as far as performance is concerned. Once we finish loading the components using the module, we shall look into expanding the model to add functionality for loading sub forms. |
|
@pirupius You have some lint and type checking issues. |
@samuelmale @pirupius @eudson In principle, I'm onboard with bringing whatever functionality we can into the backend. However, I think there are some things we should consider here:
Last point: I'd probably be happier with this if we can accomodate the "subform" terminology to something like the "reference" system. I realise that's a breaking change for OHRI forms, but that way, we avoid having two user-facing features were are a bit hard to disentangle. Ideally, we end up with a unified, intuitive single feature for including content from other forms in a single form and then for backwards compatibility, we can support "subform" as a synonym for some kind of reference with similar semantics. |
@ibacher I think we will have to go with the suggestion of your last sentence. Sub-form it is not just a reusable component as the reference componentes are. When referencing sub-forms one can post data into multiple (different) The Uganda team also wants to leverage this functionality. I believe this could have been also achieved with workflows but that feature is still not available in O3. cc: @slubwama Another cool thing of sub-forms is that they can also post to the same Regarding supporting all of this from the backend and have all cooked when loading into the frontend I think it is a good idea and worths exploring. Can I propose we have a technical meeting about the whole form-engine architecture sooner than later because I keep seeing this comments on PRs and I think it would be beneficial if we agree on certain aspects before the code is written, @pirupius has spent a lot of time on this trying to figure out the best approach |
pirupius
force-pushed
the
feat/support-reusable-components
branch
from
b75ed87 to
62d521c
Compare
| @@ -24,7 +24,7 @@ export function evaluateExpression( | |||
| if (!expression?.trim()) { | |||
| return null; | |||
| } | |||
| const allFieldsKeys = fields.map(f => f.id); | |||
| const allFieldsKeys = fields.map((f) => f.id); | |||
There was a problem hiding this comment.
This file doesn't have any code changes. Only formatting
| @@ -47,7 +47,7 @@ export function getForm( | |||
|
|
|||
| export function loadSubforms(parentForm) { | |||
| parentForm.pages = parentForm.pages || []; | |||
| parentForm.pages.forEach(page => { | |||
| parentForm.pages.forEach((page) => { | |||
There was a problem hiding this comment.
Same applies to this file. Only format changes
src/hooks/useFormJson.tsx
Outdated
| * Functions to support reusable Form Components | ||
| */ | ||
| function getReferencedForms(formJson: OHRIFormSchema): Array<ReferencedForm> { | ||
| const referencedForms: Array<any> = formJson.referencedForms; |
There was a problem hiding this comment.
what happens when formJson is undefined ?
There was a problem hiding this comment.
This has been handled with the typings and validation on the call
|
I've created a ticket to explore migration to o3forms module as well as spec'ng migration of subform to references |
|
@samuelmale @kajambiya please take another pass at this. If there no objections, will proceed and merge it and build on top of it for the other enhancements. |
|
Thanks @kajambiya |
Requirements
Summary
This PR introduces logic for support for form components previously in the Angular Form Engine as part of the feature parity milestone. The React form engine already had support for reusing forms but differed in behaviour.
Commonly asked questions?
Qn: What's the difference between sub-forms and form components?
Ans: Both features are built with reuse in mind. But differ in the way they're created, referenced and use cases.
Sub-Form: Sub Forms are what the RFE already support with a user able to reference another form. The referenced sub-form is then automatically inserted by the engine and runtime bringing with it any special functionality the subform might have as well content it has as a whole. The user isn't able to exclude questions or sections from the sub-form.
Form Components: This on the other hand is a feature that the angular form engine (AFE component docs) already had support for. With this, the user building a form had the power to reuse either part of a form component or all sections of a component. For example if you had a form for Antenatal, you could decide to use only a particular section or questions of the
component_artnot necessarily the whole component_art form.Qn: Does this impact my already existing forms with the Ampath JSON schema?
Ans: No. The main goal with this PR for already existing implementations is to provide a smooth transition without having to redesign their forms or at least make the migration less painful. For new implementations, this is an additional tool used to design forms with reuse in mind based on the business needs.
Screenshots
Related Issue
Other
A follow up PR will be made to the O3 form builder to aid faster creation and reuse of form components.