Separate dialogs from popovers #961

New Issue

dpschen · 2021-11-08T14:59:27Z

dpschen commented

2021-11-08 14:59:27 +00:00

We should separate these usecase:

popover (former modal; popover is the better naming, also allows better distinction from 'model') is used for pages, basically an overlay with a UIs.
popovers usually have a url
dialog: asking the user a question. e.g. delete.
Not sure what to do with modals that had an url but would then loose it. But this also isn't consequent right now: some delete modals have a url others don't.

Popovers should not be stacked (although we might have some exceptions).
Dialogs might be stacked, but this is also discouraged. Better would be to create a user flow where this is not needed.

See also:
#816 (comment)

We should separate these usecase: - popover (former modal; popover is the better naming, also allows better distinction from 'model') is used for pages, basically an overlay with a UIs. popovers usually have a url - dialog: asking the user a question. e.g. delete. Not sure what to do with modals that had an url but would then loose it. But this also isn't consequent right now: some delete modals have a url others don't. Popovers should not be stacked (although we might have some exceptions). Dialogs might be stacked, but this is also discouraged. Better would be to create a user flow where this is not needed. See also: https://kolaente.dev/vikunja/frontend/pulls/816#issuecomment-16745

konrad added the

kind/feature

label 2021-11-09 22:48:20 +00:00

konrad commented

2021-11-09 22:50:29 +00:00

I like the idea.

some delete modals have a url others don't.

That sounds like it should be more consistent.

Did you check which modals have a url and which don't? My guess is all modals which are accessible from the menu directly have one while the ones from a detail page don't.

I like the idea. > some delete modals have a url others don't. That sounds like it should be more consistent. Did you check which modals have a url and which don't? My guess is all modals which are accessible from the menu directly have one while the ones from a detail page don't.

dpschen commented

2021-11-11 01:45:24 +00:00

I didn't check, but that might be!
Either way still not sure which way to go here: I like that there is a direct url for e.g. editing stuff. For deleting it doesn't make so much sense, since you shouldn't be able to navigate back to a delete dialog after you pressed delete.

I didn't check, but that might be! Either way still not sure which way to go here: I like that there is a direct url for e.g. editing stuff. For deleting it doesn't make so much sense, since you shouldn't be able to navigate back to a delete dialog after you pressed delete.

👍 1

konrad added the

area/internal-code

label 2021-11-13 18:46:13 +00:00

dpschen commented

2021-11-19 17:23:15 +00:00

Because of #1037

I started implementing dialogs based on https://headlessui.dev/vue/dialog but with a promise interface.
Still iterating on that idea.

@konrad: what do you think in general?

Because of https://kolaente.dev/vikunja/frontend/issues/1037 I started implementing dialogs based on https://headlessui.dev/vue/dialog but with a promise interface. Still iterating on that idea. @konrad: what do you think in general?

konrad commented

2021-11-22 18:35:53 +00:00

If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)?

In general, I think we could move forward with it.

If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)? In general, I think we could move forward with it.

👍 1

dpschen commented

2021-11-22 20:06:56 +00:00

If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)?

Yes they implement a lot of heavy to implement accessability stuff in there.

> If I understood the docs from headless ui correctly, using their dialog component would add the focus trap (that's currently not working)? Yes they implement a lot of heavy to implement accessability stuff in there.

dpschen commented

2021-11-22 20:07:26 +00:00

I started with this already, but still in an early phase.

👍 1

dpschen commented

2021-11-27 13:21:09 +00:00

I realized that the dialogs should probably be implemented in a way that you cann them via a function that returns a promise.

Does that make sense?

I realized that the dialogs should probably be implemented in a way that you cann them via a function that returns a promise. Does that make sense?

dpschen commented

2022-05-20 16:35:03 +00:00

To remember for later: https://github.com/rlemaigre/vue3-promise-dialog