ni / nimble

The NI Nimble Design System
https://nimble.ni.dev
MIT License
32 stars 8 forks source link

Implement Nimble dialog #378

Closed gergo-papp closed 2 years ago

gergo-papp commented 2 years ago

😯 Problem to Solve

Several SystemLink web applications require a confirmation dialog (or generically just "dialog"). There is already a helium-uicomponents-based solution and an Angular Material-based one. None of these follow any design guidelines and none of them are theme-aware.

💁 Proposed Solution

Implement a nimble-dialog component and its appropriate Angular wrapper component by extending fast-dialog. This is similar to how the current nimble-drawer is implemented, but that component was specifically designed for "slide in" components that appear on the left or right side of the window.

The new component would appear in the middle of the window and would have the following sections:

Other considerations - TBD

We could benefit from a programmatic way of opening a dialog by providing a NimbleDialogService that exposes functions for programmatically configuring and opening a dialog and then subscribing to it:

nimbleDialogService.openDialog('Are you sure you want to delete a file?').subscribe(confirmed: boolean => {
    if (confrmed) {
        deleteFile();
    }
});
gergo-papp commented 2 years ago

@jattasNI @rajsite I can't decide what would be the best approach for this low-level component in nimble. Having a programmatic approach (eg using a nimbleDialogService would make things very easy on the client side), but there is additional logic required to decide where to create the component in the DOM, since clients would want this to be "inside" a nimble-theme-provider.

Alternatively we can just use an ngIf in Angular, but then there it's harder to implement this behavior purely using services and observables.

Maybe we can have a hybrid, where we provide a very basic dialog in nimble, and implement a wrapper in systemlink-lib-angular that know where to dynamically create the component.

gergo-papp commented 2 years ago

@fredvisser @jattasNI Is there any wild/rough estimate on when anyone could start working on this? I assume we should also involve POs and UX experts when creating a new component - AFAIK we do not have specs for a dialog and all the related behaviors

This is not super urgent so I don't want to pressure you but we want to know how much to invest in alternate short-term solutions

jattasNI commented 2 years ago

@gergo-papp @fredvisser as we discussed in the UI WG today, we won't get to set the priority for this until next iteration at the earliest. To unblock your team you're welcome to temporarily use a different component.

m-akinc commented 2 years ago

Consider using dialog html element in template, possibly upstreaming to FAST.

m-akinc commented 2 years ago

Needs some design/interactions guidance before we can really implement this. We presumably want nice support for common use cases like an info popup and a confirmation popup. But how much flexibility do we want to give, e.g. number, appearance, and labels of buttons? Do we want to support a fully customizable dialog, starting from a blank panel? UX/design may dictate that some of these things should stay constant/consistent. And the flexibility we expose to users will affect how we implement things, e.g. via slots or attributes.

gergo-papp commented 2 years ago

From what I saw there is always a header/title, and a primary (and optionally secondary) buttons.

The content of the dialog can them be projected - eg a client might want to show a checkbox or display additional infromation in a paragraph

TJ-G commented 2 years ago

Wanted to chime in with some feedback on requirements: I do think we'll want customization in the dialog. We would want the ability to adopt it in cases like the 'Calibration Policy' dialog we show on the assets page, where we need the user to provide more than just yes/no information: image

TrevorKarjanis commented 2 years ago

@jattasNI @rajsite I can't decide what would be the best approach for this low-level component in nimble. Having a programmatic approach (eg using a nimbleDialogService would make things very easy on the client side), but there is additional logic required to decide where to create the component in the DOM, since clients would want this to be "inside" a nimble-theme-provider.

Alternatively we can just use an ngIf in Angular, but then there it's harder to implement this behavior purely using services and observables.

Maybe we can have a hybrid, where we provide a very basic dialog in nimble, and implement a wrapper in systemlink-lib-angular that know where to dynamically create the component.

I believe the solution for this, as used by AM experimental (MDC), is portal outlets. Angular components work with HTML slots, so a portal is used to dynamically inject an Angular component into the dialog slot(s). We'll see what Mert's PR produces, but I've worked with portals extensively and can probably create the service if need be whether it lives in Nimble or the shared lib. I think portals use ViewContainerRef.createComponent, so that's also probably an option as well.

mollykreis commented 2 years ago

@m-akinc, shouldn't this issue stay open until we have Angular & Blazor support for the dialog (assuming we don't have a different issue for adding that support)?