Bug/1095/number of edges not visible

[NearW]

Fix number of edges not visible when hovering

closes #1095

Description

The bug existed, because we already started rendering when the metricData was set and didn't await the edgeMetricData. I decided that instead of adding a simple if-condition to ensure that, we should rework some stuff and finally add the metrics to the redux store. This was a huge task. Some changes are trivial, but especially the nodeMetricService/Reducer and edgeMetricService/Reducer are not.

• Removed metricService and edgeMetricDataService and created a nodeMetricData and edgeMetricData property in the redux store instead
• Moved all logic that involves calculating and setting the state to it's reducer (you can now set the state by dispatching an action)
• Moved all logic that involves retrieving information from the state to the corresponding service
• Created two new types NodeMetricData and EdgeMetricData and used the previous MetricData for the parent-reducer
• Created a new event metric-data-complete that is triggered, when both node and edge metric data is calculated
• Fixed bug by listening to that event and rendering when all the metric data is available
• Removed all occurrences of jest.resetAllMocks() since they're not doing anything anyway
• Changed edge-metrics being sorted by name now as we do with the node-metrics instead of by number of incoming and outgoing edges

In order to review this, check out the two new services I created and check every file that just required small changes (such as fixing the import and injecting the new service). I can help you with the rest then. :)

ToDo

• Add regression test

Definition of Done

A task/pull request will not be considered to be complete until all these items can be checked off.

• All requirements mentioned in the issue are implemented
• Does match the Code of Conduct and the Contribution file
• Task has its own GitHub issue (something it is solving)
  • Issue number is included in the commit messages for traceability
• Update the README.md with any changes/additions made
• Update the CHANGELOG.md with any changes/additions made
• Enough test coverage to ensure that uncovered changes do not break functionality
• All tests pass
• Descriptive pull request text, answering:
  • What problem/issue are you fixing?
  • What does this PR implement and how?
• Assign your PR to someone for a code review
  • This person will be contacted first if a bug is introduced into master
• Manual testing did not fail

[BridgeAR]

Needs a rebase

[BridgeAR]

Thanks for following up on the comments! This is shaping nicely!

[BridgeAR]

Suggested change

	public getMaxMetricByMetricName(metricName: string): number {
	public getMaxMetricByMetricName(metricName: string): number | undefined {

I could imagine that metric is always truthy due to just accepting known metricNames (I suggest to use an enum to guarantee that metricName is always known).

[NearW]

Yes, we only call this method on metrics we know exist.

How can we build an enum dynamically containing only the metrics that are relevant to the visible files though?

[NearW]

@BridgeAR Great suggestions. I decided that we should sort the edge-metrics the same way, we sort the node-metrics (by name). This way, I was able to resolve the duplicate of the sort-function.

[BridgeAR]

@NearW do you have a before and after screenshot for the change? :-)

[NearW]

Before:

After:

Edge-Metrics will be sorted the same way, we sort the node-metrics: By name. Before they were sorted by the max-value of incoming and outgoing edges. Sorting them by max-value isn't a bad idea, but we should handle both metrics the same way in my opinion.

I also pushed another huge performance improvement for huge maps.