feat(q-dialog): Add configurable option to not close dialog when clicking button fix: #17120

[dongwa]

#17120

What kind of change does this PR introduce?

• Bugfix
• Feature
• Documentation
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes
• No

The PR fulfills these requirements:

• It's submitted to the dev branch (or v[X] branch)
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested on a Cordova (iOS, Android) app
• It's been tested on an Electron app
• Any necessary documentation has been added or updated in the docs or explained in the PR's description.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to start a new feature discussion first and wait for approval before working on it)

Other information:
Title: Add notHide Option to props.ok to Control Dialog Closure on Button Click

Summary:
Introduce a new notHide option within props.ok to allow control over dialog visibility when the OK button is clicked. This feature will be particularly useful for scenarios where the dialog should remain open until an asynchronous task completes.

Description:
Currently, the dialog closes immediately when the OK button is clicked. However, for certain operations, like asynchronous tasks, it may be necessary to keep the dialog open until the operation is fully completed. Implementing a notHide property will provide developers with the flexibility to prevent the dialog from closing right away.

Proposed Solution:

• Add a notHide boolean property to props.ok.
• When notHide is set to true, the dialog will not close upon clicking the OK button.
• The dialog closure can be manually triggered later, typically after the completion of an asynchronous operation.

Example Use Case:
Consider a form submission within a dialog where data validation and server-side processing are required. With the notHide option set to true, the dialog remains open, displaying a loading indicator while the submission is processed. Once the server responds, the dialog can be programmatically closed, either on success or after displaying an error message.

[github-actions]

UI Tests Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 8bc0525.

[Zhouyy999]

Yes, we really hope that the official can merge this PR, as this scenario is very common in actual business

[rstoenescu]

Hi,

Thank you for contributing to Quasar! We really appreciate it.
However, in this case it saddens me to have to say that we must stick to our principles:

We have explained numerous times that the default Dialog plugin should cover most of the user-cases, but definitely not all possible ones. Should one need some custom behavior that is not currently supplied, a custom component should be created and invoked instead.

The alternative is to open the Pandora's box and allow all of the requests/PRs and end up with a bloated + complex + non-efficient + hard to grasp component, which is not what we want to achieve.
So sorry, but will close this PR :(