If the footer property is a Templates.render() promise, and the modal is
set to show immediately (show=true), the show() logic - which contains
the footer show/hide logic - can run before the footer content is set
(i.e. before the promise chain is complete). In such cases, the footer
will be marked as hidden and must be made visible again.
This change includes some additional simplifications to support this
change, including conversion from done/fail to then/catch, and some
simplification of Promise usage.
There were a number of cases of nested Modal usage which have been
removed.
This commits adds a new static `create()` method to replace the existing
ModalFactory.create approach.
This allows the creation of a modal to now be simplified to:
```js
import SomeModalClass from 'mymodule/wherever';
// ...
const modal = await SomeModalClass.create();
```
Prior to this change the modal was instantiated via the ModalFactory,
but the Type of modal was typically pulled from the ModalClass itself
via the registry. Essentially it used to require three modules to
instantiate a single Modal, and now it takes just one.
This change moves configuration of the modal from the ModalFactory to
a new `configure` function on the Modal class which does exactly the
same thing. This means that the API is fully encapsulated within the
Modal, and an individual Modal can specify its own configuration more
easily.
This change will make it much easier to instantiate new modals,
significantly reducing boilerplate in many instances.
This change allows modals to extend the `configure()` method to provide
their own defaults, or to override standard ones.
```js
class MyModal extends Modal {
static TYPE = 'my_module/mymodal';
static TEMPLATE = 'my_module/mymodal';
configure(params = {}) {
// Override the default value for large.
params.large = true;
super.configure(params);
// Handle our own properties here.
const {
makeSound = true,
} = params;
this.setSoundEmitter(makeSound);
}
```
Prior to this change, it was common to see this happen in the _calling_
code, rather than the modal itself.
This addresses a random failure with the combobox search results where
the debounce causes the results to be shown, and then the same search
result is returned again, re-rendered, and replaced after Behat has
moved on.
Autocomplete fields can now include disabled options in the suggestion
list. When calling .enchance() on a select list with disabled options,
those options will be added to the autocomplete suggestions with the
aria-disabled arribute set, and will not be selectable.
Datafilters using the autocomplete element can also hook into this by
including disabled options in their list of values.
A datafilter can now specify a subset of jointypes that it supports from
the default list of all, any or none. By default all options will be
available, but an individual filter can ovveride this to include just
those options that make sense for the filter. If only one option is
allowed, the select list will be hidden to simplify the UI.
As we migrate to primarily using natives promises, we should make it
easier to use and consume them.
This change:
- updates core/str to add new methods for:
- getString
- getStrings
- accept Native promises into Modal setters
This allows datafilters to include additional fields other than the standard list of selected values.
For example they may wish to include an additional select or checkbox to change how the values are used in the resulting query.
Many times the action menu item triggers modals to show more information
to the user. In most cases this is enough, however, a modal will close
the menu and the user is not able to see the modal content in the page
context. To solve this now menus can define subpanels that are displayed
next the the menu item when the item is focused or hover. This will be
used to group options like the group mode in activities or to replace
the adhoc solution implemented to select language in the user menu.
Add a new global module to get information from the page. Some methods
are just local functions moved to as a global library. For example, the
drawers isSmall or isLarge to detect the page width. The other funcionts
added are to detect focusable elements and they are needed to loop on
elements, especially when accessibility keyboard navigation is implemented.
When an AMD dialogue is opened from a YUI dialogue, the YUI dialogue is
not actually removed from the DOM, but was counted in z-index
calculation.
We need to stop including it otherwise nested AMD => YUI => AMD
dialogues get broken.
Jake Dallimore