Move to this type of styling
https://www.ag-grid.com/angular-data-grid/global-style-customisation-compactness/

I could not get their example code to work. will distill into a minimally reproducible test case and either fix or file a bug with ag-grid

Currently Commands are prototypes for operations that accept a column or colspec as an option.

Design a UI for row-wise options, and develop commands that work against them.

Examples could include "remove all rows where column A is above 20"
Split into two dataframes... based on column A above or below 20.

Summary stats

Add a base no-arg summary statistics function, that can operate on either the input DataFrame or transformed DataFrame. enable a toggle via the UI

Try to limit display to 5 rows

Column level features

for text columns

display number of discrete values vs total number of rows
If there are only a couple of discrete values show those values

If there are a limited number of outliers, show them

for integer and float columns

Show a histogram sparkline
list quartiles
medina, mean, stddev

Currently most of the front end is built as a separate repo, https://github.com/paddymul/dcf-widget-npm . Bring that repo into the main dcf repo.

We could have only a single js/ts build step... I would prefer to keep the frontend in a separate npm package. The dcf-widget-npm repo (containing only the react component - no ipywidget or jupyter widget stuff... poor name for the repo) has a much cleaner js build setup vs the main dcf repo. This fosters collaboration with frontend devs.

Add this text to the README when the code changes have been completed

What is the difference between a command and an operation?

A command is closer to a function, it is the definition of a transform step. An operation is an invocation of a command with concrete arguments.

The UI reads the list of Commands, along with their argspecs and presents them in the UI. Using them to build a list of operations.

Commands include a python function to actually perform the transformation, a python function to emit the equivalent python code, and argspecs describing the expected arguments for the Command.

---

Previously invocations of commands and commands, and commands themselves were called Command (with extra explanatory endings). @zainhoda helped the disambiguation in a pairing session. Most of the changes have been made to frontend react widget... they need to be carried through to the backend python code.

The codebase is largely untested because it was built in a rapid prototyped "can this even work" style since I was dealing with new technologies. As the shape of the system has become clearer, it's time to add unit tests to prevent regressions.

Here are the main areas that can be tested

Transform interpreter

• Does it properly perform the transformations?
• Can we add a Command and then use it
• What do errors look like?
• Can we build in testing to the Command class?

Py_Code_Gen interpreter

• does the generated python code produce the same output as the corresponding transform python code when evaled

Widget python side

• Do observers get properly called... can we set a property/model attribute and verify that the proper observer was called and state exists as expected.

Widget ts code (widget side)

• can we instantiate the widget with known values and verify that no errors exist
• do the sent python types match the typescript types expected

widget react code

• Can we instantiate and display each component without errors
• do the weird setter gymnastics work properly with a widget-ts analogue (add explanation)