(fix) O3-4320: Remove Irrelevant Properties When Changing Question Type

[Bharath-K-Shetty]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
• My work includes tests or is validated by existing tests.

Summary

This PR implements functionality to clean up form field data when a user changes a question's type in the form builder. A mapping of allowed properties for each question type is defined, and a helper function (cleanFormFieldForType) ensures that only the properties relevant to the newly selected question type are retained. The solution also cleans the nested questionOptions object based on a separate mapping, ensuring required keys like "rendering" remain intact.

Screenshots

Screen.Recording.2025-02-10.183846.mp4

Related Issue

https://openmrs.atlassian.net/browse/O3-4320

Other

[Bharath-K-Shetty]

@NethmiRodrigo review required..!

[NethmiRodrigo]

Thanks @Bharath-K-Shetty! A couple of suggestions:

[Bharath-K-Shetty]

@NethmiRodrigo updated the pr..!

[NethmiRodrigo]

@Bharath-K-Shetty left a few comments. Please add unit tests to cover this scenario

[NethmiRodrigo]

@Bharath-K-Shetty looks like this isn't as simple as what I had initially thought. While this is halfway there, we have to consider the propeties specific for renderingTypes as well (as per https://openmrs.atlassian.net/wiki/spaces/docs/pages/68681754/Field+Types+Reference), which means there needs to be a bit more rework that needs to be done on this PR. You can do it and I can guide you through it, but if its a hassle, I can do it. What do you prefer?

[Bharath-K-Shetty]

Hey @NethmiRodrigo i think for cleanup of rendering Type there is a separate ticket focusing on that can you please clarify once.Ticket:https://openmrs.atlassian.net/browse/O3-4319

[NethmiRodrigo]

Hey @NethmiRodrigo i think for cleanup of rendering Type there is a separate ticket focusing on that can you please clarify once.Ticket:https://openmrs.atlassian.net/browse/O3-4319

Yeah, I thought we could handle it separately, but now seeing it in action, I don't think we can do them seperately

[NethmiRodrigo]

@Bharath-K-Shetty you'd have to reconsider the properties you added for questionType since some of them are for renderingType

[NethmiRodrigo]

'required` is a common property

[NethmiRodrigo]

Please see this comment again

[NethmiRodrigo]

'minLength', 'maxLength' are properties relevant to text rendering type and not specific to the control question type

[NethmiRodrigo]

Similarly, isSearchable is for ui-select-extended rendering type

[NethmiRodrigo]

@Bharath-K-Shetty So what I do to find the correct properties is, I go through the FormField type definition - https://github.com/openmrs/openmrs-esm-form-engine-lib/blob/d28f37f92cff6c6e97b3339113d921e880400855/src/types/schema.ts#L60 because most often than not they are pretty self explanatory. Similarly, - https://openmrs.atlassian.net/wiki/spaces/docs/pages/68681754/Field+Types+Reference for renderingType. Most of what you have put for questionType you'd see is actually what should be under renderingType

[NethmiRodrigo]

@Bharath-K-Shetty I've left a few comments, but the more I think about this, the more this approach seems to be unscalable, especially because I was thinking of all the possible combinations of questionType to renderingType we'd have to consider. Seems like the best way forward is to rework this to:

1. When changing the question type or rendering type, we just remove all the properties except id, label and required
2. Show a info tooltip next to the question type and rendering type that on hover would show a warning that changing the type would remove properties.
   Over time, we'll probably evolve this into a better solution, but I think this proposed approach would be a much better and less complex task (and easier to test).
   Sorry about the iterative changes, this is a ticket that I hadn't thought about in such depth until now

[NethmiRodrigo]

Since these test cases are explicitly for testing the functions within the question-utils file and doesn't test anything within the question.component itself, it would be better to add these to a question-utils.test file. A test case that you could write for the question.component would be something like loading a formField like:

const formField: FormField = {
      id: 'testQuestion',
      label: 'Test Question',
      type: 'obs',
      questionOptions: {
        rendering: 'radio',
        concept: '12345',
        answers: [
          { concept: '111', label: 'Yes' },
          { concept: '222', label: 'No' },
        ],
      },
      required: true,
    };

and then rendering the question component, and then clicking on the Select Type and changing the type and then checking if setFormField gets called with the unnecessary properties removed

[NethmiRodrigo]

Actually, the label property is not required for questions that have the renderingType markdown

Suggested change

// In our design, label is required for all question types, so it should remain.

[NethmiRodrigo]

Instead of asserting property by property, can't we have a result object and assert that the cleaned object is equal to that, i.e:

const expectedObjectAfterClean = {
      id: 'testQuestion',
      type: 'control',
      questionOptions: {
        rendering: 'markdown',
        concept: '12345',
      },
      required: true,
}
expect(cleaned).toEqual(expectedObjectAfterClean);

[NethmiRodrigo]

Please see this comment again

[NethmiRodrigo]

Suggested change

	markdown: ['rendering', 'concept'],
	markdown: ['rendering'],

[NethmiRodrigo]

The following are types relevant to this:

 extensionId?: string;
 extensionSlotName?: string;

[NethmiRodrigo]

Also relevant type: step?: number;

[NethmiRodrigo]

Relevant to this: repeatOptions?: RepeatOptions;

[NethmiRodrigo]

allowedFileTypes?: Array<string>;

[NethmiRodrigo]

 programUuid?: string;
 workflowUuid?: string;