Window / Dialog component - replaces direct use of Blueprint dialog

[amcclain]

We make frequent and direct use of the Blueprint Dialog out of kit. There are some concrete issues with this:

• In general we want to avoid needing to go into kit for core components, as it reduces our flexibility to swap out third-party library comps for alternate implementations.
• Can't use these same components cross-platform.
• BP dialogs make use of inner header/footer components / classes which I find somewhat ambiguous (are they required? do we use them consistently?) and have some styling / sizing differences from our other comps (namely toolbars and Panel headers).
• No support moving / resizing / maximizing.

We could consider:

• Lightweight wrapper around Dialog to avoid the kit imports, or...
• Wholesale replacement of Dialog - could be done via addition of floating / positioned support to Panel.

[lbwexler]

I was actually thinking it might be interesting to offer something like XH.dialog() or XH.window() that would popup a window or dialog imperatively, much like messages get popped-up with XH.message(). That way, applications would not need to have to deal with the whole "isOpen" bookkeeping and needing to place the thing manually into the virtual DOM. Question is how to to specify buttons and how to allow the content in the dialog the ability to close the window....

[cnrudd]

For the first step BP dialog wrapper component with defaulted props: these are the BP defaults to use to turn off open/close animations:

transitionDuration: 0,
transitionName: ‘none’

[cnrudd]

Lee and I reviewed the code in branch 'hoistDialog', which produces a draggable/resizeable dialog or fixed pos/size dialog.

We determined we want to make Dialog a function component with its own model (much like Panel).

Model should have these API properties and methods:

Properties

1. showTitleBar: boolean
2. showCloseButton: boolean
3. showMaxMinButtons: boolean
4. resizable: boolean
5. draggable: boolean
6. closeOnEscape: boolean
7. closeOnMaskClick: boolean
8. zIndex: integer
9. stateful: string (stateId?)
10. width: number or string px / % (explore other units)
11. height: number or string px / %
12. isOpen: boolean (readonly)?

(All properties should be observable)

Methods

1. show
2. hide

Component should take these props:

1. title: String
2. icon: Element

Also explore if same dialog component can be used on mobile. Maybe not allow resizable or draggable on mobile.

[cnrudd]

Still to do:

• [x] manage zIndex (auto incr for popup upon popup), but let zIndex be specified to overwrite auto zIndex

  • [x] make a useMask config (boolean) for showing or not showing a full size background mask. (right now this is on by default if dialog is not draggable/resizeable, and off otherwise, but there could be use cases for opposite config.

• [x] some code cleanups: maybe unify plain dialog and draggable/resizable dialog, cleanup setting of size&pos state in 2 uses cases of having & not having stateModel

• [x] store position and size in pref and use that if present - done with local storage state model.

• [x] add inPortal model config option (default to true). When false, dialog would be added to the DOM tree at the place in which the dialog component was added in code. When false, a dialog hopefully cannot be dragged outside of its containing DOM element.

• [x] make a non-draggable, non-resizable, non-positioned dialog that auto centers stay centered if the user resizes the window.

• [x] try to use more computed and observable logic on x,y,width,size props

• [x] make resizable/maximizable test dialog in non-portal parent container

• [x] add width/height controls into test page toolbar

• [x] when maximized, disable resizing by drag handles

• [x] support resizable without specifying width & height

• [x] take 2nd look at setting width without requiring height or vice versa

• [ ] support % or strings as width/height

• [ ] add anchorRef config: this would be a config object that takes either an x or y or an element ref, and if an elementRef, an anchor string like: 'bottom-left-top-left' (default) or 'bottom-right-top-right' for aligning the dialog's corner to an element's corner After researching this, I think this would be better categorized as its own ticket, in which we developed a 'positioning lib' to implement this feature.

[amcclain]

Leaving this here in case relevant at all - https://tympanus.net/codrops/2021/10/06/how-to-implement-and-style-the-dialog-element/