mediawiki-extensions-Echo/modules/ui/mw.echo.ui.NotificationsListWidget.js

247 lines
6.5 KiB
JavaScript
Raw Normal View History

( function () {
/**
* Notifications list widget.
* All of its items must be of the mw.echo.ui.NotificationItem type.
*
* @class
* @extends mw.echo.ui.SortedListWidget
*
* @constructor
* @param {mw.echo.Controller} controller Echo notifications controller
* @param {mw.echo.dm.ModelManager} manager Model manager
* @param {Object} [config] Configuration object
* marked as read when they are seen.
* @cfg {string} [timestamp=0] A timestamp representing the latest item in
* the list.
* @cfg {jQuery} [$overlay] A jQuery element functioning as an overlay
* for popups.
*/
mw.echo.ui.NotificationsListWidget = function MwEchoUiNotificationsListWidget( controller, manager, config ) {
config = config || {};
// Parent constructor
mw.echo.ui.NotificationsListWidget.super.call(
Fix fade-in/out animation in sorting The fade in/out animation is asynchronous. This means that if we are sorting multiple items one after the other, by the time the item faded out, it will be reinserted back into the wrong position, breaking the sorting. This also broke the promise of OO.SortedEmitterList whereby all its items are always in order. The way to fix this was to force a better synchronization with the item order while we hide and show the item in its new place. To do that, a new widget is created as a fake clone of the old one, in the original position of the old one. The original item is then reinserted (while hidden) to the proper location -- preserving order. The fake clone is then faded out, and the real item is then faded in. For this to work properly, the cloned item had to preserve some of the original item's information, like timestamp, foreigness and id. However, since both the real item and the fake new clone have the same details, the clone fakes its ID by adding a fraction to it - promising that the fallback in case of equal timestamps (which happens on the real and cloned items) will still resolve with some decision about the placement of the items rather than (falsely but understandably) decide they are both the same. Since this whole animation is somewhat of a hack, the list now has a configuration parameter to turn the animation on. The animation is on in the popups, but off in the special page. Bug: T141419 Change-Id: Ic7c35e5ddefc51bf7fde497eab36414b4dddcd9e
2016-07-29 23:35:29 +00:00
this,
// Sorting callback
function ( a, b ) {
if ( !a.isRead() && b.isRead() ) {
return -1; // Unread items are always above read items
} else if ( a.isRead() && !b.isRead() ) {
return 1;
} else if ( !a.isForeign() && b.isForeign() ) {
return -1;
} else if ( a.isForeign() && !b.isForeign() ) {
return 1;
}
// Reverse sorting
if ( b.getTimestamp() < a.getTimestamp() ) {
return -1;
} else if ( b.getTimestamp() > a.getTimestamp() ) {
return 1;
}
// Fallback on IDs
return b.getId() - a.getId();
},
config
);
// Initialize models
this.controller = controller;
this.manager = manager;
this.models = {};
// Properties
this.$overlay = config.$overlay || this.$element;
this.timestamp = config.timestamp || 0;
// Dummy 'loading' option widget
this.loadingOptionWidget = new mw.echo.ui.PlaceholderItemWidget();
this.resetLoadingOption();
this.manager.connect( this, {
update: 'resetDataFromModel',
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
discard: 'onModelManagerDiscard'
} );
this.$element
.addClass( 'mw-echo-ui-notificationsListWidget' );
};
/* Initialization */
OO.inheritClass( mw.echo.ui.NotificationsListWidget, mw.echo.ui.SortedListWidget );
/* Events */
/**
* @event modified
*
* The content of this list has changed.
* This event is to state that not only has the content changed
* but the actual DOM has been manipulated.
*/
/* Methods */
Relate read-state filter and mark read/unread action When we are viewing a certain read state filter ('read' or 'unread') the visibility of items should correspond to that state even when the user marks a specific item as read/unread. That means that the system should remove these items from view when the action is taken. In this commit: * The controller makes the judgment of whether to remove items when read/unread action is taken, based on whether a filter is set. * We clean up the terminology of discard - no more 'remove' - to make sure we have consistency in the code. * Related: The 'discard' event is now scoped within the hierarchy; meaning, lists emit 'discard' when an item is removed, grouplist emits 'discard' when a group is removed, and the manager emits 'discard' when an entire notification model is removed. This means we can actually have proper hierarchy and organization with a single event, and not worry about clashing between the intentional 'discard' action and the event 'remove' that is also used while resorting happens. * The model manager emits a discard event when a model is removed so that the general list can listen to the manager and remove an entire batch of items if needed. * The pagination model now updates the count for the current page rather than some vague notion of the last page. This is also updated when the controller removes items, so we can get an accurate count in the page for the number of notifications that are displayed. Bug: T136891 Change-Id: I247c618042ef256fadf09922f7b83bd1ad361f64
2016-07-14 00:03:57 +00:00
mw.echo.ui.NotificationsListWidget.prototype.onModelManagerDiscard = function ( modelName ) {
var i,
items = this.getItems();
// For the moment, this is only relevant for xwiki bundles.
// Local single items will not get their entire model removed, but
// local bundles may - when that happens, the condition below should
// also deal with local bundles and removing them specifically
if ( modelName === 'xwiki' ) {
for ( i = 0; i < items.length; i++ ) {
if ( items[ i ] instanceof mw.echo.ui.CrossWikiNotificationItemWidget ) {
this.removeItems( [ items[ i ] ] );
this.checkForEmptyNotificationsList();
return;
}
}
}
this.emit( 'modified' );
};
/**
* Respond to model manager update event.
* This event means we are repopulating the entire list and the
* associated models within it.
*
* @param {Object} models Object of new models to populate the
* list.
* @fires modified
*/
mw.echo.ui.NotificationsListWidget.prototype.resetDataFromModel = function ( models ) {
var i, modelId, model, subItems, subItem, widget,
itemWidgets = [],
$elements = $();
// Detach all attached models
for ( modelId in this.models ) {
this.detachModel( modelId );
}
// Attach and process new models
for ( modelId in models ) {
model = models[ modelId ];
this.attachModel( modelId, model );
// Build widgets based on the data in the model
if ( model.isGroup() ) {
if ( model.isForeign() ) {
// One Widget to Rule Them All
widget = new mw.echo.ui.CrossWikiNotificationItemWidget(
this.controller,
model,
{
Fix fade-in/out animation in sorting The fade in/out animation is asynchronous. This means that if we are sorting multiple items one after the other, by the time the item faded out, it will be reinserted back into the wrong position, breaking the sorting. This also broke the promise of OO.SortedEmitterList whereby all its items are always in order. The way to fix this was to force a better synchronization with the item order while we hide and show the item in its new place. To do that, a new widget is created as a fake clone of the old one, in the original position of the old one. The original item is then reinserted (while hidden) to the proper location -- preserving order. The fake clone is then faded out, and the real item is then faded in. For this to work properly, the cloned item had to preserve some of the original item's information, like timestamp, foreigness and id. However, since both the real item and the fake new clone have the same details, the clone fakes its ID by adding a fraction to it - promising that the fallback in case of equal timestamps (which happens on the real and cloned items) will still resolve with some decision about the placement of the items rather than (falsely but understandably) decide they are both the same. Since this whole animation is somewhat of a hack, the list now has a configuration parameter to turn the animation on. The animation is on in the popups, but off in the special page. Bug: T141419 Change-Id: Ic7c35e5ddefc51bf7fde497eab36414b4dddcd9e
2016-07-29 23:35:29 +00:00
$overlay: this.$overlay,
animateSorting: this.animated
}
);
} else {
// local bundle
widget = new mw.echo.ui.BundleNotificationItemWidget(
this.controller,
model,
{
$overlay: this.$overlay,
Fix fade-in/out animation in sorting The fade in/out animation is asynchronous. This means that if we are sorting multiple items one after the other, by the time the item faded out, it will be reinserted back into the wrong position, breaking the sorting. This also broke the promise of OO.SortedEmitterList whereby all its items are always in order. The way to fix this was to force a better synchronization with the item order while we hide and show the item in its new place. To do that, a new widget is created as a fake clone of the old one, in the original position of the old one. The original item is then reinserted (while hidden) to the proper location -- preserving order. The fake clone is then faded out, and the real item is then faded in. For this to work properly, the cloned item had to preserve some of the original item's information, like timestamp, foreigness and id. However, since both the real item and the fake new clone have the same details, the clone fakes its ID by adding a fraction to it - promising that the fallback in case of equal timestamps (which happens on the real and cloned items) will still resolve with some decision about the placement of the items rather than (falsely but understandably) decide they are both the same. Since this whole animation is somewhat of a hack, the list now has a configuration parameter to turn the animation on. The animation is on in the popups, but off in the special page. Bug: T141419 Change-Id: Ic7c35e5ddefc51bf7fde497eab36414b4dddcd9e
2016-07-29 23:35:29 +00:00
bundle: false,
animateSorting: this.animated
}
);
}
itemWidgets.push( widget );
$elements = $elements.add( widget.$element );
} else {
subItems = model.getItems();
// Separate widgets per item
for ( i = 0; i < subItems.length; i++ ) {
subItem = subItems[ i ];
widget = new mw.echo.ui.SingleNotificationItemWidget(
this.controller,
subItem,
{
$overlay: this.$overlay,
bundle: false
}
);
itemWidgets.push( widget );
$elements = $elements.add( widget.$element );
}
}
}
// Reset the current items and re-add the new item widgets
this.clearItems();
// fire render hook
mw.hook( 'ext.echo.notifications.beforeRender' ).fire( this.$element, $elements );
this.addItems( itemWidgets );
this.checkForEmptyNotificationsList();
this.emit( 'modified' );
};
/**
* Attach a model to the widget
*
* @param {string} modelId Symbolic name for the model
* @param {mw.echo.dm.SortedList} model Notifications list model
*/
mw.echo.ui.NotificationsListWidget.prototype.attachModel = function ( modelId, model ) {
this.models[ modelId ] = model;
};
/**
* Detach a model from the widget
*
* @param {string} modelId Notifications list model
*/
mw.echo.ui.NotificationsListWidget.prototype.detachModel = function ( modelId ) {
this.models[ modelId ].disconnect( this );
delete this.models[ modelId ];
};
/**
* Reset the loading 'dummy' option widget
*
* @param {string} [label] Label for the option widget
* @param {string} [link] Link for the option widget
* @fires modified
*/
mw.echo.ui.NotificationsListWidget.prototype.resetLoadingOption = function ( label, link ) {
this.loadingOptionWidget.setLabel( label || '' );
this.loadingOptionWidget.setLink( link || '' );
if ( this.isEmpty() ) {
this.addItems( [ this.loadingOptionWidget ] );
}
this.emit( 'modified' );
};
/**
* Check if the list of notifications is empty and udpate the placeholder
* widget as needed.
*/
mw.echo.ui.NotificationsListWidget.prototype.checkForEmptyNotificationsList = function () {
this.resetLoadingOption( this.isEmpty() ? mw.msg( 'echo-notification-placeholder' ) : '' );
};
/**
* Reset the 'initiallyUnseen' state of all items
*/
mw.echo.ui.NotificationsListWidget.prototype.resetInitiallyUnseenItems = function () {
var i,
itemWidgets = this.getItems();
for ( i = 0; i < itemWidgets.length; i++ ) {
itemWidgets[ i ].resetInitiallyUnseen();
}
};
}() );