fix(ui): prevent parameter editor from resetting when props update (fixes #14351)

[k4r1]

Fixes #14351

Explanation
The UI is continually making calls to appdetails and syncwindows when viewing an Application or its settings.

When this happens it updates the input passed to the <DataLoader /> inside the application-parameters component, which causes it to re-run its load function. Without setting noLoaderOnInputChange to true, this causes the component to render loading... momentarily every time the input prop changes, before switching back to what was there before once the load function completes.

Because the component has an "edit" mode, this can be problematic as the switch to "loading..." and back causes the component to reset to its base state, losing the change the user might be in the middle of making. I believe this is what is being described in the referenced issue, and our users have the same problem.

The PR simply sets noLoaderOnInputChange to true, as seems to be done in a handful of other UI components elsewhere in the app. From testing locally this appears to fix the issue*.

*Note: To get my local environment to work at all I had to add the option chaining operator ?. to all instances of sourceHydrator.currentOperation for some reason - I don't know if this is an issue with my local env or if it's a problem in the master branch but that change is not included in this PR.

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• The title of the PR conforms to the Toolchain Guide
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them. (N/A)
• Does this PR require documentation updates? (No)
• I've updated documentation as required by this PR. (N/A)
• I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
  • Doesn't seem necessary
• My build is green (troubleshooting builds).
• My new feature complies with the feature status guidelines. (N/A)
• I have added a brief description of why this PR is necessary and/or what this PR solves.
• Optional. My organization is added to USERS.md.
• Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity). (?)
  • I'm not sure - we use 2.11.2 but can upgrade - ideally this would at least be cherry-picked into a stable version so we can roll it out soon.

[bunnyshell]

❗ Preview Environment stop on Bunnyshell failed

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

• 🔴 /bns:stop to stop again the environment
• 🔵 /bns:start to start the environment
• 🚀 /bns:deploy to redeploy the environment
• ❌ /bns:delete to remove the environment

[k4r1]

If it's helpful, here's what it looks like before the fix (I'm not refreshing the page or clicking cancel, this is what it does by itself):

Screen.Recording.2025-01-29.at.12.38.47.PM.mov

The app keeps switching back to the loading state as it initiates a reload of the data while it's waiting for a response. This isn't actually what we want, it should be fine to keep the existing data rendered until the response comes in, which is what that flag I've enabled does.

Switching to the loading state actually unmounts the editing component, losing all the in-progress work and resetting its state. And for some apps the refresh is so frequent that editing parameters simply isn't possible.

It's definitely worse for some apps than others, but for the ones it affects it's pretty consistently problematic, and a source of a lot of user complaints coming our way.

I know it looks like quite a trivial change but it took quite a lot of effort to identify and patch and fixes a very real issue - it would be great if we could get this upstreamed so we don't have to run/maintain a fork to work around the issue. Is there anything extra needed in this PR to make that happen?