Resolve perf issues on the search page

[tiffon]

Fix #178.

Main issue was two too many stateless functional components, now React.PureComponents.

Also:

• No longer mutating the array of search results when sorting it
• Added a couple of missing util css imports

[codecov]

Codecov Report

Merging #179 into master will increase coverage by 0.03%.
The diff coverage is 87.5%.

@@            Coverage Diff             @@
##           master     #179      +/-   ##
==========================================
+ Coverage   90.77%   90.81%   +0.03%     
==========================================
  Files          93       93              
  Lines        1930     1937       +7     
  Branches      383      383              
==========================================
+ Hits         1752     1759       +7     
  Misses        155      155              
  Partials       23       23

Impacted Files	Coverage Δ
src/index.js	0% <0%> (ø)	⬆️
src/components/SearchTracePage/index.js	88.37% <100%> (+1.19%)	⬆️
...onents/SearchTracePage/SearchResults/ResultItem.js	100% <100%> (ø)	⬆️
.../components/SearchTracePage/SearchResults/index.js	92.3% <87.5%> (ø)	⬆️
...neViewer/TimelineHeaderRow/TimelineViewingLayer.js	90.74% <0%> (+3.7%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7a3e74...139ab07. Read the comment docs.

[black-adder]

just curious, are there automated ways to detect regressions like this in the UI?

[tiffon]

@black-adder jaegertracing/jaeger-client-node/benchmarks is one approach. Another is testing through a browser with something like Puppeteer for Chrome — similar to e2e testing but you'd want to capture a perf trace via the dev tools. The former is granular while the latter has sweeping coverage but variance is likely to be a problem.

What's the approach taken with the various Jaeger benchmarks to have some sort of historical perspective or expectation relative to the current benchmark results? E.g. the current perf is X, the new perf is Y.

[saminzadeh]

Main issue was two too many stateless functional components, now React.PureComponents.

To clarify, the issue is not necessarily stateless components but rather unnecessary render comparisons right? The PureComponent will add the shouldComponentUpdate lifecycle method to do a shallow comparison of props and state to avoid unnecessary renders.

Another alternative would be to keep the components stateless and then use a simple utility like recompose's pure or onlyUpdateForKeys HOCs that would only result in a few lines of code change.

The result would be a smaller code change and easier to remove when we optimize further up the state tree:

export function ResultItem(props) { /*... */ }

export default pure(ResultItem);

[tiffon]

Another alternative would be to keep the components stateless and then use a simple utility like recompose's pure or onlyUpdateForKeys HOCs that would only result in a few lines of code change.

@saminzadeh That's a great point. My inclination is to use React.PureComponent, but it's a tough call...