2018-05-08 18:24:11 +00:00
|
|
|
<td data-test-icon class="is-narrow">
|
|
|
|
|
{{#if node.unhealthyDrivers.length}}
|
2018-10-17 14:17:24 +00:00
|
|
|
<span class="tooltip text-center" role="tooltip" aria-label="Client has unhealthy drivers">
|
2018-05-08 18:24:11 +00:00
|
|
|
{{x-icon "warning" class="is-warning"}}
|
|
|
|
|
</span>
|
|
|
|
|
{{/if}}
|
|
|
|
|
</td>
|
2018-01-05 20:59:36 +00:00
|
|
|
<td data-test-client-id>{{#link-to "clients.client" node.id class="is-primary"}}{{node.shortId}}{{/link-to}}</td>
|
|
|
|
|
<td data-test-client-name class="is-200px is-truncatable" title="{{node.name}}">{{node.name}}</td>
|
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
|
|
|
<td data-test-client-composite-status>
|
2019-06-19 17:11:17 +00:00
|
|
|
<span class="tooltip" aria-label="{{node.status}} / {{if node.isDraining "draining" "not draining"}} / {{if node.isEligible "eligible" "not eligible"}}">
|
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
|
|
|
<span class="{{compositeStatusClass}}">{{node.compositeStatus}}</span>
|
2019-06-19 17:11:17 +00:00
|
|
|
</span>
|
2018-05-29 17:36:09 +00:00
|
|
|
</td>
|
2018-05-29 17:06:48 +00:00
|
|
|
<td data-test-client-address>{{node.httpAddr}}</td>
|
2018-01-05 20:59:36 +00:00
|
|
|
<td data-test-client-datacenter>{{node.datacenter}}</td>
|
|
|
|
|
<td data-test-client-allocations>
|
2017-09-19 14:47:10 +00:00
|
|
|
{{#if node.allocations.isPending}}
|
|
|
|
|
...
|
|
|
|
|
{{else}}
|
|
|
|
|
{{node.allocations.length}}
|
|
|
|
|
{{/if}}
|
|
|
|
|
</td>
|
