After investigation, we all agreed that fixed-data-table-2 [1] is a potential candidate react library for building our request list, which also provides a set of needed features for our use case e.g. resizable column, expanded rows, fluid column widths...etc. Team is going to conduct an experiment to demonstrate how it looks like in request list, and find out potential performance regression. [1] http://schrodinger.github.io/fixed-data-table-2/

Here is an example of a netmonitor-mimics table with using fixed-data-table-2. * Resizable column * Fluid column width * Responsive Column * Scroll to bottom Example: https://rickychien.github.io/netmonitor-fixed-data-table/example-netmonitor.html Code: https://github.com/rickychien/netmonitor-fixed-data-table/blob/master/examples/NetMonitorExample.js

(In reply to Ricky Chien [:rickychien] from comment #1) > Created attachment 8925428 [details] If you are going to try out this, please do not run `./mach build & ./mach build faster` since the current patch only work in launchpad.

the patch is outdated due to the recent netmonitor css split change, could you rebase the PR?

I'm using hg pull -r 6f833f70ecbf33b64e12fe81538e74978e095c8a https://reviewboard-hg.mozilla.org/gecko for pulling entire branch to avoid such conflict. If you're using git, please revert to previous commit (1 or 2 days ago).

Base on current experiment patch, the perf is slower than original implementation. In order to not cause perf regression to Netmonitor, we should stop introducing fixed-data-table-2 ATM. Fixed-data-table-2 is still a good candidate for building rich features table, perhaps we can come back if the major perf issue is fixed. I'm going to unassign myself ATM.

Moving to p3 because no activity for at least 24 weeks. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information