UI: Polling Step 3 - Close connections when tabbing away

[DingoEatingFuzz]

Since browsers only support ~6 open connections to the same host at once, it's important to eagerly close connections to allow other tabs to resolve requests.

Example problem scenario:

1. Visit /clients in Tab A
2. /clients has n + 1 connections, 1 for the nodes list and n for the allocations of each node
3. Open a client in a new tab (Tab B)
4. Tab B is in a perpetual loading state because Tab A has already hit the maximum allowed open connections for the nomad server host

Solved problem scenario:

1. Visit /clients in Tab A
2. /clients has n + 1 connections, 1 for the nodes list and n for the allocations of each node
3. Open a client in a new tab (Tab B)
4. Once Tab B is active, the n + 1 connections in Tab A are all aborted
5. Tab B loads immediately because there are currently 0 open connections to the nomad server host

[meirish]

Will you ever have > 1 component with this mixin on a screen? Would you have a last one wins situation here?

[alisdair]

I think all components (or routes) would have their handlers run, right? Which is likely the desired behaviour.

[DingoEatingFuzz]

Yes to both! Job row and node row both mix this mixin in, so multiple components. Yes all components own their own handler and independently add and remove their own handlers. This prevents accidental side effects when paginating or sorting resulting in one component being destroyed and bringing down all the visibility handlers.

[meirish]

mixin the mixin 🐢🐢🐢

[meirish]

❤ little usage helpers like this

[meirish]

I guess I have the same question about nested routes as I do with multiple components - do outer routes have their handler overwritten by child routes here?

[DingoEatingFuzz]

Nope, independent handlers again.

[alisdair]

This is super cool! 😎

On the new mixins: there's an implicit dependency on the visibilityHandler method on the object using the mixin. This feels a little bit tricky to me. Is there any reasonable way of making that dependency more explicit?

[DingoEatingFuzz]

Is there any reasonable way of making that dependency more explicit?

Good call. Something like what I did with the default startWatchers in the other mixin?

nomad/ui/app/mixins/with-watchers.js

Lines 16 to 18 in df54b6b

	startWatchers() {
	assert('startWatchers needs to be overridden in the Route', false);
	},

[alisdair]

Yeah, the assert approach seems great to me! 👍

[meirish]

Cool 👍! Fun that it was a relatively small change too.

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.