Handle nested dialogs inside dialog-form

[dev-reedus]

Breaking change

Proposed change

This PR fixes how nested dialogs are handled, now when opening a dialog, the dialog manager stores dialog as singleton. Trying to open another dialog within it, makes dialog manager to overwrite the first one, leaving his promise hanging forever with no result.
This way opening a dialog within dialog-form, make it calls stop propagation to prevent dialog manager handle it, then creates a "local" dialog-form and appends it to its own shadow root, and of course manages its lifecycle locally. This fix works with any nesting depth (even if I didn't find a real use case of this one).
Also changed how render label/description of list items. Now when the fields is an object, fell through Array.join that produces [object Object]. This way object are resolved using selector label_field, to show which nested fields have been set, if there is no label_field falls to stringify(). The fallback has been hardened the same way.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes Nested object selectors are not saved when pressing Add #28844
• This PR is related to issue or discussion: #28844
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to backend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• There is no commented out code in this PR.
• I have followed the perfect PR recommendations
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hello @dev-reedus,

When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).

The commits that are missing a linked GitHub account are the following:

• df02586abc4fc5df160eaab19f2a531209c9eb4f - No email found attached to the commit.

Unfortunately, we are unable to accept this pull request until this situation is corrected.

Here are your options:

1. If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

2. If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

   • If you only made a single commit you should be able to run

     git commit --amend --author="Author Name <email@address.com>"
     

     (substituting "Author Name" and "email@address.com" for your actual information) to set the authorship information.
   • If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:
     1. You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
     2. You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.
   • Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.

Thanks, I look forward to checking this PR again soon! ❤️

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

[home-assistant]

Hi @dev-reedus

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

Stale

[MindFreeze]

The whole approach seems a bit hacky.
I'm fine with fixing this in dialog-form instead of centrally in the dialog manager because I don't think we have this use case elsewhere. The manager intentionally doesn't allow stacking the same dialog on top of itself. The idea was that if a dialog needs this, it would just manage it's internal state better.
So I think the right approach is to keep a stack of states in the dialog without creating child dialogs in the shadow DOM. So when a new show-dialog comes in, save the current params somewhere and apply the new ones from the show-dialog event. Then do the reverse on close/save.

[dev-reedus]

@MindFreeze Thanks for suggestions, I changed dialog-form, so now it stores a stack of dialogs even when there is only 1. Now data and params are stored inside this stacked list. I have just a question, since I'm new to Lit and webComponents: is it ok to use lit keyed directive on ha-form (dialog-form) so it re-renders every change on nested dialog and reflects changes, or should I update parent data of nested dialogs instead (in this case ha-selector-object)? (second option is probably more reliable)

[MindFreeze]

ha-form is already reactive to .schema / .data, so when you push the outer state onto a stack and swap in the nested params, Lit will re-render the form correctly. keyed would force a full destroy/recreate of ha-form on every push and pop, which is unnecessary and slower.
Manually updating the parent's data isn't needed either, the existing event flow handles it.

[dev-reedus]

Updated how dialog-form handle nesting:

• added new state _stack to handle stacked dialogs data
• handle multiple nested values like: root: {value1: {[]}, value2: {[]}} or root: {level1: {level2: {[]}}} these are edge uses cases, but still allowed when writing yaml of blueprints.

These are the steps when opening a nested dialog:

1. intercepts show-dialog fired inside dialog-form and is handled by _handleNestedShowDialog
2. Read origin.name from event composedPath and set value to nestedField to handle multiple fields on nested level
3. Pushes {params, data, nestedField} to _stack to save parent state
4. Replace _params, _data with the new nested dialog data

While submitting:

1. Calls submit of element to resolve ha-selector-object promise (fires into void)
2. _popStack() restores _params and _data of parent element
3. Looks for nestedField in parent data, to update it locally with new value, and check if is a multiple selector. If multiple append data to existing array, otherwise just replace value. If there is no nestedField value, it just spread data

So nested value is stored locally to dialog-form until original dialog is submitted.

I also updated how nested values are rendered inside ha-selector-object.

[wendevlin]

Thanks a lot 🚀

Approved