Jordan Santell [:jsantell] [@jsantell] Reporter
	Description • 9 years ago

Copied from the thread on the mailing list[3]:

We have a range of widgets with overlapping/duplicated functionality, some
rotting with no updates, and many fixes/polish for tools are in these
widgets themselves. To have a cohesive widget story that’s shared across
our tools would be a solid win, ideally sharing features across tools for
free (imagine if all of our table views were instantly sortable/resizable!).

Some potential goals this endeavor would achieve are:
* Remove/reduce neglected current widgets
* Share widget features across tools
* Any refactoring/new widgets have an opportunity to kill XUL in a component
* New components we do not have and need (resizable/sortable table, only
render in view list)
* Take advantage of React/redux combo on tools that use it for differential
rendering

There are a few ways we could go about this — based on an audit of our
widgets, most of the duplicated code revolve around tree, lists and tables.
Lists can be thought of as a subset of trees, whereas adding table
functionality can extend either. Whether or not these all should extend
from the same core widget, not sure. To go about this process, we should
make/choose a widget that solves the issues, and begin wiring it up to
current tools, dropping depreciation messages in current widgets, and
ultimately remove them. We have a lot of cruft here.

At the bottom is an audit of implementations and consumers for each of the
types (tree, list, table). This was spawned from a discussion[0] about
adding sortable/resizable columns in the performance call tree, which isn’t
possible because it’s not really a table. In terms of tree-table
requirements based on our current bugs across several tools, the following
would achieve what we need:

* Only render visible items
* Custom line items for each consumer of widget
* Tree capabilities (expand/collapsible)
* Table capabilities (sortable, resizable, reorderable?)

For the tree implementation, the one that seems the most complete in all
the functionality above, except table capabilities, fitzgen’s Tree in the
initial memory tool prototype from years ago[1]. If we can identify a
robust/flexible way to implement a table-tree widget, it would handle the
table widget problem (all top level tree items), as well as the list widget
(all top level tree items, single “column”), and a normal tree widget
(single “column”).

If this sounds good and like something we want to tackle in the future,
let’s talk about how we’re going to do just that, and I’ll make some bugs.
I love making bugs.

*Widget Audit - List Widgets (4 implementations, 5 current consumers)*
* webconsole (custom)
* Netmonitor (custom)
* FastListWidget
  * Vestigial includes in Debugger (can be removed)
* SimpleListWidget
  * Debugger (global search, watch expressions, results panel)

*Widget Audit - Tree Widgets (5 implementations, 14 current consumers)*
* Abstract Tree Widget
  * Performance (call tree/allocations, waterfall)
* TreeWidget
  * storage, jit optimizations
* VariablesView
  * Webconsole, web audio, storage, scratchpad, tooltips?, netmonitor,
debugger, webide (manifest)
* JSONResponseViewer Tree?[2]
* Heap Tree View (fitzgen’s patch on memory tool prototype)[1]

*Widget Audit - Table Widgets (1 implementation, 2 consumers)*
* Table Widget
  * storage, webconsole (console.table?)

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1201742
[1]
https://bugzilla.mozilla.org/attachment.cgi?id=8487436&action=diff#a/browser/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1132203
[3] https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/hH_VBUx_rZA