Make DynamicDialog more flexible, fix docs #5679
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request aims to improve the DynamicDialog by making it a bit more flexible to use and also fix a few annoying gripes i've found with it (especially with handling emits and props):
Here's a quick summary:
Allow for
container
templatePretty self explanatary, it will allow the dynamicDialog to also have a "headless" mode similar to the Dialog component itself.
Move content component into obj
This is caused by the point above, since you don't need a content component if you're declaring the container directly.
Seperate child component props & emits
I've noticed that there's no official documented way to send props to the child component so i've dug deeper and found out that emits just v-bind's directly to the child component. Theoretically you could use
options.emits
to pass props but i've found it kinda weird to use and not logical.Rename dialogProps to seperate from child component props
Since the dialog also has it own props i've reused the
options.props
for the child component (similar tooptions.emits
) and moved the dialog props intooptions.dialogProps
.The changes i've made are ❗BREAKING❗ but i think they offer enough value to justify the additional migration step when updating the library.