Use a streamlined way to trigger component dismiss

[GeoSot]

Till this MR:

• plugins that support dismiss action by clicking on a data-bs-dismiss trigger, can be dismissed ONLY if the trigger is inside the plugin html.

• Alert, makes the difference. Alert on data-bs-dismiss click, tries to parse a data-bs-target element and in case in null, it fallback on the standard way, that assumes the trigger is inside the plugin html

This MR:

introduces the enableDismissTrigger helper function, that streamlines the functionality, using the idea of Alert component.

When 'dismiss' is clicked, it searches for getElementFromSelector(event.target) || this.closest(.${Plugin.NAME}) .

Result:

1. The dismiss trigger can be either inside the component, or with the use of data-bs-target it can be anywhere in doc
2. the dismiss trigger will respect the disable state and will handle preventDefault in case it is an anchor

The idea came from #33324

[alpadev]

How about defining enableDismissTrigger on the base-component? That way you could use it like Plugin.enableDismissTrigger(callback) and don't have to pass the plugin.

[GeoSot]

I don't know if it is ok to use it as static, as it will leave open the possibility to be called outside the code, causing fault usages

[alpadev]

bootstrap/js/src/modal.js

Lines 144 to 146 in 34218da

	if (event && ['A', 'AREA'].includes(event.target.tagName)) {
	event.preventDefault()
	}

do we still need this here?

[alpadev]

bootstrap/js/src/alert.js

Line 49 in 34218da

const rootElement = element ? this._getRootElement(element) : this._element

bootstrap/js/src/alert.js

Lines 61 to 63 in 34218da

	_getRootElement(element) {
	return getElementFromSelector(element) || element.closest(`.${CLASS_NAME_ALERT}`)
	}

This is covered by enableDismissTrigger too, isn't it?

[GeoSot]

bootstrap/js/src/modal.js

Lines 144 to 146 in 34218da

	if (event && ['A', 'AREA'].includes(event.target.tagName)) {
	event.preventDefault()
	}

do we still need this here?

As we still support anchors with href triggers, I think yes.

bootstrap/js/src/alert.js

Line 49 in 34218da

const rootElement = element ? this._getRootElement(element) : this._element

bootstrap/js/src/alert.js

Lines 61 to 63 in 34218da

	_getRootElement(element) {
	return getElementFromSelector(element) || element.closest(`.${CLASS_NAME_ALERT}`)
	}

This is covered by enableDismissTrigger too, isn't it?

Is better to merge #33402 before this MR, because existing alert code, does some 'magic', and makes me nervous, using other code

After #33402 is merged, we won't have to solve this riddle

[alpadev]

bootstrap/js/src/modal.js

Lines 144 to 146 in 34218da

	if (event && ['A', 'AREA'].includes(event.target.tagName)) {
	event.preventDefault()
	}

do we still need this here?

As we still support anchors with href triggers, I think yes.

But this is done by enableDismissTrigger already? And from looking at the code there is no other call to hide() that passes an event?

[ffoodd]

As said in #33324, I'm a bit concerned about usability and accessibility. The refactor looks great, but use cases that it'd allow feel wrong.

Modal (and offcanvas) are supposed to make everything outside them inert while they're opened. Toast and alerts are IMHO valid use cases, but I'm not sure about this as a feature.

[ffoodd]

As said in #33403, this might need technical docs. Depending on this, we may need to add a callout regarding accessibility risks, but I guess we're pretty safe as long as we don't promote weird use cases.

[mdo]

Love the consolidation of code and docs!