feat: implement row striping options

[rich-iannone]

This PR addresses #435 by making row striping options functional in rendered tables. An example of using row striping involves three new options in tab_options():

from great_tables import GT, exibble

(
    GT(exibble[["num", "char", "row", "group"]], rowname_col="row", groupname_col="group")
    .tab_options(
        row_striping_include_table_body=True,
        row_striping_include_stub=True,
        row_striping_background_color="lightblue"
    )
)

Alternatively, the opt_row_striping() method allows for a simplified shortcut for row_striping_include_table_body=True so the user doesn't have to look through tab_options() for this basic functionality:

from great_tables import GT, exibble

(
    GT(exibble[["num", "char", "row", "group"]], rowname_col="row", groupname_col="group")
    .opt_row_striping()
)

Note that the default background color for striping is a very light gray (by design).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.80%. Comparing base (fd3ac52) to head (663fce8).
Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #461      +/-   ##
==========================================
+ Coverage   86.77%   86.80%   +0.03%     
==========================================
  Files          42       42              
  Lines        4749     4760      +11     
==========================================
+ Hits         4121     4132      +11     
  Misses        628      628              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[machow]

If #460 looks good, once we merge it and update the build should pass again!

[machow]

This is too big. Can you reduce it to a snapshot that is mostly limited to the piece being tested, or test it another way?

[machow]

Can you test this further upstream? If rendered html strings are the very last step, is there an earlier step that indicates these two approaches do the same thing (e.g. checking the options values directly, etc..)?

[rich-iannone]

I'll check the options values directly here (comparing the two approaches).

[machow]

See comment on snapshot. It'd be okay to test the css and html separately if it makes it easier to strip down. I wonder if you could easily test the css using an assertion, and snapshot test just the html body (with fewer rows of data; the minimum needed to test--3? or w/e makes sense given there are groupings; no need to have all columns in the snapshot please strip down)

[rich-iannone]

I'm going to make the input df with much smaller dimensions and only snapshot the table body (everything inside <tbody>). I don't think there's a need to snapshot the CSS part.

[machow]

This is looking good, so just a small nit here 😅. Do you mind consolidating so there is a bit less duplicated code? Seems like the following could happen:

• change variables like td_classes and th_classes to have the same name. Similar with th_classes_str, etc..
• add a variable like el_name that is either "th" or "td"
• move all other logic (e.g. the appending of "gt_striped", the " ".join, the body_cells.append) out of the if / else, so it is only written once (e.g. move it to line 543 and unindent)
  • Use el_name in what should now be a single piece of code creating the final th or td string.

It looks like if something is a stub, that only affects the element name and some of the classes to be set. (But other logic is being included)

[rich-iannone]

Thanks, will make these changes!

[machow]

Can you test these separately, so that we know if one option is specified, it does not set both things?

[rich-iannone]

Good idea. There is now two distinct snapshots where one tests striping only of the stub, the other only of the body cells.

[machow]

Yo, thanks for all these tweaks, it's beautiful!

[rich-iannone]

Thanks @machow! Always a pleasure.