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';
|
2020-06-10 13:49:16 +00:00
|
|
|
import { classNames, tagName } from '@ember-decorators/component';
|
|
|
|
import classic from 'ember-classic-decorator';
|
2017-09-19 14:47:10 +00:00
|
|
|
|
2020-06-10 13:49:16 +00:00
|
|
|
@classic
|
|
|
|
@tagName('tr')
|
|
|
|
@classNames('client-node-row', 'is-interactive')
|
2021-12-28 16:08:12 +00:00
|
|
|
export default class ClientNodeRow extends Component.extend(
|
|
|
|
WithVisibilityDetection
|
|
|
|
) {
|
2020-06-10 13:49:16 +00:00
|
|
|
@service store;
|
2018-02-16 19:02:43 +00:00
|
|
|
|
2020-06-10 13:49:16 +00:00
|
|
|
node = null;
|
2017-09-19 14:47:10 +00:00
|
|
|
|
2020-06-10 13:49:16 +00:00
|
|
|
onClick() {}
|
2017-09-19 14:47:10 +00:00
|
|
|
|
|
|
|
click(event) {
|
2019-03-26 07:46:44 +00:00
|
|
|
lazyClick([this.onClick, event]);
|
2020-06-10 13:49:16 +00:00
|
|
|
}
|
2017-09-19 14:47:10 +00:00
|
|
|
|
|
|
|
didReceiveAttrs() {
|
2021-12-28 14:45:20 +00:00
|
|
|
super.didReceiveAttrs();
|
2017-09-19 14:47:10 +00:00
|
|
|
// 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
|
|
|
}
|
2020-06-10 13:49:16 +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
|
|
|
}
|
|
|
|
}
|
2020-06-10 13:49:16 +00:00
|
|
|
}
|
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();
|
2020-06-10 13:49:16 +00:00
|
|
|
super.willDestroy(...arguments);
|
|
|
|
}
|
2018-02-16 19:02:43 +00:00
|
|
|
|
2020-06-10 13:49:16 +00:00
|
|
|
@watchRelationship('allocations') watch;
|
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-10 13:49:16 +00:00
|
|
|
@computed('node.compositeStatus')
|
|
|
|
get compositeStatusClass() {
|
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
|
|
|
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 '';
|
|
|
|
}
|
2020-06-10 13:49:16 +00:00
|
|
|
}
|
|
|
|
}
|