Current behaviour The only way to display a notification is to construct one and drop the instance:
new XWiki.widgets.Notification(message, 'info');
This is the documented contract of the widget – its own comment in notification.js states "To display a notification, it suffices to create a new XWiki.widgets.Notification object" – and it works, because the constructor calls show() unless the inactive option is set. A reader has to know the widget's contract to understand that the statement does anything at all. The SonarCloud issues SonarCloud raises javascript:S1848 ("Objects should not be created to be dropped immediately without being used") on every such call site, currently 21 of them across 12 JavaScript files, and it is a BUG-severity rule so these count against the reliability rating and the new-code quality gate. Each one is a false positive that has to be triaged by hand, and every new call site adds another. The 21 open javascript:S1848 issues this change could close Proposed improvement Add a static factory next to the existing XWiki.widgets.Notification.textFormat and XWiki.widgets.Notification.getContainer statics:
XWiki.widgets.Notification.show = (text, type, options) => new XWiki.widgets.Notification(text, type, options);
Call sites then read:
XWiki.widgets.Notification.show(message, 'info');
Backward compatibility Fully additive. The constructor is unchanged and keeps working, so no existing caller inside or outside the platform breaks. Extensions can feature-detect the new method the same way they already feature-detect textFormat. Scope Beyond adding the method, fixing the sonar warning would imply migrating the call sites that instantiate a notification purely for the side effect: 31 statements in .js files and 60 in wiki-page .xml files, 91 in total. The remaining ~179 uses of the constructor assign the instance to a variable and already read fine; they are left alone. |
