UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
import Mixin from '@ember/object/mixin';
|
|
|
|
|
import Ember from 'ember';
|
|
|
|
|
import { computed } from '@ember/object';
|
|
|
|
|
import { warn } from '@ember/debug';
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
Sortable mixin factory
|
|
|
|
|
|
|
|
|
|
Simple sorting behavior for a list of objects. Pass the list of properties
|
|
|
|
|
you want the list to be live-sorted based on, or use the generic sortable.js
|
|
|
|
|
if you don’t need that.
|
|
|
|
|
|
|
|
|
|
Properties to override:
|
|
|
|
|
- sortProperty: the property to sort by
|
|
|
|
|
- sortDescending: when true, the list is reversed
|
|
|
|
|
- listToSort: the list of objects to sort
|
|
|
|
|
|
|
|
|
|
Properties provided:
|
|
|
|
|
- listSorted: a copy of listToSort that has been sorted
|
|
|
|
|
*/
|
|
|
|
|
export default function sortableFactory(properties, fromSortableMixin) {
|
2021-12-28 14:45:20 +00:00
|
|
|
|
const eachProperties = properties.map((property) => `listToSort.@each.${property}`);
|
UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
2020-06-09 21:03:28 +00:00
|
|
|
|
// eslint-disable-next-line ember/no-new-mixins
|
UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
return Mixin.create({
|
|
|
|
|
// Override in mixin consumer
|
|
|
|
|
sortProperty: null,
|
|
|
|
|
sortDescending: true,
|
2021-12-28 14:45:20 +00:00
|
|
|
|
listToSort: computed(function () {
|
2020-06-09 21:03:28 +00:00
|
|
|
|
return [];
|
|
|
|
|
}),
|
UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
|
|
|
|
|
_sortableFactoryWarningPrinted: false,
|
|
|
|
|
|
|
|
|
|
listSorted: computed(
|
|
|
|
|
...eachProperties,
|
2021-02-17 21:01:44 +00:00
|
|
|
|
'_sortableFactoryWarningPrinted',
|
UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
'listToSort.[]',
|
|
|
|
|
'sortDescending',
|
2021-02-17 21:01:44 +00:00
|
|
|
|
'sortProperty',
|
2021-12-28 14:45:20 +00:00
|
|
|
|
function () {
|
UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
if (!this._sortableFactoryWarningPrinted && !Ember.testing) {
|
|
|
|
|
let message =
|
|
|
|
|
'Using SortableFactory without property keys means the list will only sort when the members change, not when any of their properties change.';
|
|
|
|
|
|
|
|
|
|
if (fromSortableMixin) {
|
|
|
|
|
message += ' The Sortable mixin is deprecated in favor of SortableFactory.';
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
warn(message, properties.length > 0, { id: 'nomad.no-sortable-properties' });
|
2020-06-09 21:03:28 +00:00
|
|
|
|
// eslint-disable-next-line ember/no-side-effects
|
UI: Fix client sorting (#6817)
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
2019-12-12 19:06:54 +00:00
|
|
|
|
this.set('_sortableFactoryWarningPrinted', true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const sorted = this.listToSort.compact().sortBy(this.sortProperty);
|
|
|
|
|
if (this.sortDescending) {
|
|
|
|
|
return sorted.reverse();
|
|
|
|
|
}
|
|
|
|
|
return sorted;
|
|
|
|
|
}
|
|
|
|
|
),
|
|
|
|
|
});
|
|
|
|
|
}
|