Replies: 1 comment
-
|
Maybe not applicable in every situation, but in one project a needed multiple of such awaitable dialogs: async def confirm_delete_project_dialog(project: Project) -> str | None:
"""Show a dialog to confirm deleting a project."""
with ui.dialog() as dialog, ui.card():
ui.label(f'Are you sure you want to delete the project "{project.name}"?')
with ui.row().classes("ml-auto"):
ui.button("Cancel", on_click=lambda: dialog.submit(None)).props("flat")
ui.button("Delete", on_click=lambda: dialog.submit(True), color="negative").props("unelevated")
result = await dialog
dialog.delete()
return result |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
In our little project we have 3 devs, and all 3 would implement the dialog differntly.
So I started out thinking about how to handle the ui.dialog implementations in the project to streamline the process and I was consindering some sort of base/abstract dialog interface to enforce that all implemented dialogs inside the project are using singletons with classmethod, alternativ I would use the clear()/open() standart but that made me think, why do we have the overload at the user?
So I thought about a concept of a new argument in the dialog
Which could be used like
Personaly I dont like decorators so much, but I am not sure if adding another argument "build_function" would be better.
This could be an optional style to rebuild the dialogs ( I am not sure if the dom must cleared too).
So I am a little bit curious how do other people enforce reusable/clean dialogs inside their projects?
Beta Was this translation helpful? Give feedback.
All reactions