Simplify Webview Architecture

After the new designs, all that remains in the table Webview is displaying the Experiments as a table:

This, along with a shift toward native UI elements like TreeViews, means we need to move a lot of the webview logic into the extension and, ideally, not duplicate work within the Webview. Since the webview handles a lot right now, it’s best to break this into steps

Tasks

From a high level, one can consider refactoring out the columns a task that can be handled separately from moving over the experiments themselves. From there, both tasks can be broken up into a sequence of smaller tasks.

Columns can be fully reimplemented can before starting on experiments, and doing to will allow us to work on both refactoring the Webview and building on the Columns data in parallel.

• Columns

  • Parse and expose the column schema in Extension (#358)
  • DRY-ly use the extension-parsed columns in the Webview table
  • Add native UI elements for column control (#359 #362 #363), which can be usable pre-experiments by puppeting react-table’s filter/sort/hide state
  • Remove Webview columns UI

• Experiments

  • Parse experiments (turn the object into an array, organize baselines and checkpoint_tips into the hierarchy they represent) in the extension
  • Sort experiments in the extension
  • Filter experiments in the extension
  • Remove sort/filter logic from Webview and consume from Extension
  • Make a native UI to keep track of experiments at a glance

Other considerations:

• We could explore using command URI links instead of JS-based message passing
• With so much less responsibility, we can use a much lighter and simpler state solution for the webview, like useReducer

[rogermparent]

1. Was talking with a friend last night about having to move all of the data to the extension and could not articulate exactly why the data couldn’t live in the React model along with sorting and filtering options. what I am talking about is a single copy of the data in the Webview along with extra information about sorting and filtering. I think there is going to have to be two way communication about hiding / sorting columns anyway but like I said, I must be missing something.

I don’t blame you for considering this, my reasoning for moving most of the state into the Webview would be that the new design moves most of the sort/filtering UI into native UI widgets like Treeviews and Quickpicks, so the Experiments UI as a whole is going to become just as involved with the Extension side as it is the Webview side, if not more so.

I believe it makes more sense to change the Webview to consume a new Extension-side Experiments data source than it would be to make all the new native UI bits have to work with data message-passed from the Webview.

[mattseddon]

I must be missing something, I’ll go back and look at the design again on Monday.

The reason that I was asking was:

1. Breaking up the work into smaller chunks always helps with velocity.
2. Feels like we were getting close to a POC that we could actually do a beta release with and dismantling what we have instead of incrementally moving to the correct design derails that.
3. Was talking with a friend last night about having to move all of the data to the extension and could not articulate exactly why the data couldn’t live in the React model along with sorting and filtering options.

For 3 what I am talking about is a single copy of the data in the webview along with extra information about sorting and filtering. I think there is going to have to be two way communication about hiding / sorting columns anyway but like I said, I must be missing something.

Have a good weekend, see you in the future 👍🏻 .