2018-02-16 19:02:43 +00:00
|
|
|
import { inject as service } from '@ember/service';
|
2017-12-15 21:39:18 +00:00
|
|
|
import Component from '@ember/component';
|
2017-09-26 18:57:46 +00:00
|
|
|
import { lazyClick } from '../helpers/lazy-click';
|
2018-02-16 19:02:43 +00:00
|
|
|
import { watchRelationship } from 'nomad-ui/utils/properties/watch';
|
2018-03-06 22:16:43 +00:00
|
|
|
import WithVisibilityDetection from 'nomad-ui/mixins/with-component-visibility-detection';
|
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 { computed } from '@ember/object';
|
2017-09-19 14:47:10 +00:00
|
|
|
|
2018-03-06 22:16:43 +00:00
|
|
|
export default Component.extend(WithVisibilityDetection, {
|
2018-02-16 19:02:43 +00:00
|
|
|
store: service(),
|
|
|
|
|
2017-09-19 14:47:10 +00:00
|
|
|
tagName: 'tr',
|
|
|
|
classNames: ['client-node-row', 'is-interactive'],
|
|
|
|
|
|
|
|
node: null,
|
|
|
|
|
|
|
|
onClick() {},
|
|
|
|
|
|
|
|
click(event) {
|
2019-03-26 07:46:44 +00:00
|
|
|
lazyClick([this.onClick, event]);
|
2017-09-19 14:47:10 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
didReceiveAttrs() {
|
|
|
|
// Reload the node in order to get detail information
|
2019-03-26 07:46:44 +00:00
|
|
|
const node = this.node;
|
2017-09-19 14:47:10 +00:00
|
|
|
if (node) {
|
2018-02-16 19:02:43 +00:00
|
|
|
node.reload().then(() => {
|
2019-03-26 07:46:44 +00:00
|
|
|
this.watch.perform(node, 100);
|
2018-02-16 19:02:43 +00:00
|
|
|
});
|
2017-09-19 14:47:10 +00:00
|
|
|
}
|
|
|
|
},
|
2018-02-16 19:02:43 +00:00
|
|
|
|
2018-03-06 22:16:43 +00:00
|
|
|
visibilityHandler() {
|
2018-03-06 22:27:01 +00:00
|
|
|
if (document.hidden) {
|
2019-03-26 07:46:44 +00:00
|
|
|
this.watch.cancelAll();
|
2018-03-06 22:16:43 +00:00
|
|
|
} else {
|
2019-03-26 07:46:44 +00:00
|
|
|
const node = this.node;
|
2018-03-06 22:16:43 +00:00
|
|
|
if (node) {
|
2019-03-26 07:46:44 +00:00
|
|
|
this.watch.perform(node, 100);
|
2018-03-06 22:16:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2018-02-16 19:02:43 +00:00
|
|
|
willDestroy() {
|
2019-03-26 07:46:44 +00:00
|
|
|
this.watch.cancelAll();
|
2018-02-16 19:02:43 +00:00
|
|
|
this._super(...arguments);
|
|
|
|
},
|
|
|
|
|
|
|
|
watch: watchRelationship('allocations'),
|
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
|
|
|
|
|
|
|
compositeStatusClass: computed('node.compositeStatus', function() {
|
|
|
|
let compositeStatus = this.get('node.compositeStatus');
|
|
|
|
|
|
|
|
if (compositeStatus === 'draining') {
|
|
|
|
return 'status-text is-info';
|
|
|
|
} else if (compositeStatus === 'ineligible') {
|
|
|
|
return 'status-text is-warning';
|
2020-01-31 20:55:24 +00:00
|
|
|
} else if (compositeStatus === 'down') {
|
|
|
|
return 'status-text is-danger';
|
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
|
|
|
} else {
|
|
|
|
return '';
|
|
|
|
}
|
|
|
|
}),
|
2017-09-19 14:47:10 +00:00
|
|
|
});
|