Dispatch events with both CustomEvent and jQuery

[TiTidom-RC]

Description

Problem
Currently, only core Jeedom events (hardcoded list) can use [dispatchEvent] (native CustomEvent). Plugins are forced to use jQuery only.

Solution
Removed the restricted event list. All events (core and plugins) now use :

• [dispatchEvent] : for all events (native standard)
• jQuery [trigger] : maintained for events with data (backward compatibility, like before)

Events are now dispatched using both the native CustomEvent API and jQuery's trigger for backward compatibility. This ensures that all listeners, regardless of implementation, receive the events.

Suggested changelog entry

Support natif des CustomEvent pour les plugins

Related issues/external references

Fixes #

Types of changes

• Bug fix (non-breaking change which fixes)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the [La ligne directrice pour contribuer à ce projet / Contribution guidelines for this project).
• I grant the project the right to include and distribute the code under the GNU.
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added MD documentation for the sniff.

[NebzHB]

Hello, maybe add a subscription system or something ? to not overflood listeners ?

[Salvialf]

Hello,

Dispatching both natively and via jQuery for the same event risks more than just duplicate execution, the two firings wouldn't even behave consistently. jQuery's .on() already registers a real addEventListener under the hood, so the native dispatchEvent() alone already reaches jQuery-bound handlers, but without the data in the handler's expected second argument, it lands in event.originalEvent.detail instead. The explicit .trigger() call right after then fires the same handler a second time, this time with the data where jQuery-based code actually expects it. So a jQuery-based listener would run twice, with the first run likely receiving undefined where it expects its data.

Given it'll probably take a long time before every plugin has migrated its listeners to vanilla JS, an opt-in path seems safer than a blanket switch: keep an extensible jeedom.vanillaEvents array, and only skip the jQuery .trigger() for event names a plugin explicitly registers into it once its own JS has fully moved to addEventListener. Everything else keeps the current jQuery-based behavior unchanged. See #3416 for the implementation.