Issues with the peers page

Sorting

• #909 introduced lexographic sorting of the peers by multiaddr
• #1068 allows the user to sort per column

We don’t need both, or at least, we don’t need to always sort by multiaddr in the selectPeers function, if we’re going to sort by something else later on.

• Remove sorting by multiaddr, it is replaced by sorting by connection type.
• Fix location sorting on peers page.
• Check the performance of sorting with large lists of peers.
  • known issues with >4000 peers (some notes in https://github.com/ipfs-shipyard/ipfs-webui/pull/1262#pullrequestreview-306242986)
• Update geoip dataset (#1249)

Caching

• #1071 introduces caching the location for an IP. The geoip look up is where most of the work happens. We should remove caching by PeerID, as it’s totally reasonable for PeerIDs to move IP addresses.

Rendering

• As pointed out in #1071 we get d3 to render a dot per peer. Many peers get geolocated to the same city, and the map is at global scale, so we can optimise this to only render a dot per city / unique location.
• The peers table should fill the available vertical space on screens with larger vertical height.

Complexity

• We do a lot of work in peer-locations.js to expose the internal logic of the queuing of geoip look-ups as state in redux. We are not visualising the queue, nor do we plan to, so i suspect the code could be written more simply. We could extend the work in #1071 to encapsulate the geoip look up queue and caching in a class, and simply have it periodically update the redux state with batches of locations as they are found, rather than have all the queuing logic managed in redux.

[JustMaier]

I’ll take a stab at the sorting issues 👍

[olizilla]

@JustMaier Yep, feel free to change the display order of the location.

What if we adjust the table update logic so that it only updates if you are not interacting with it?