Move to a react dashboard

[Liam-DeVoe]

Closes #7, #17. Most of the react code was written by claude, and touched up by me.

• The stack is trio + starlette + hypercorn + react + scss
• For building/distributing:
  • I've moved entirely to pyproject.toml for building, with a custom build hook, and am requiring the developer have npm installed in their host system to build.
  • For distribution, I'm building the .html in dist/* as part of the build step and am uploading that as part of the compiled .whl. It should just work ™️ when installed normally (untested).
• I'm following BEM for structuring scss rules. I've used this style guide before and have enjoyed it, but am not opposed to an alternative. (to be clear, this is not a running dependency or anything, just a style guide).

TODO:

• check patches/pycrunch recordings, I've probably broken these
• feature parity with old dashboard: per-test covering examples somewhere, since new cov on test overview page
• unify overview / test coverage graph styling
• coverage details on hover in graph

This dashboard is still missing some stuff compared to the existing one, but it is runnable 😄

[Zac-HD]

eh, I think I'm OK with taking out pycrunch if it's annoying to update; it's a really nice concept but is early-alpha stability and there's no nice way to support it with distributed fuzzing (since the recordings are often hundreds of megabytes)

I'm also increasingly keen on the reconstructed-as-if-one-run view (cf #45 (comment)), but that's definitely a future PR.

[Liam-DeVoe]

pycrunch/pytrace should be doable to update. I'll do that, and then we should ship this, since it also fixes compatibility with newer hypothesis versions (hopefully the last of those now that namings have settled down).

[Zac-HD]

I've spun this up locally, and it looks great! I'll leave some more notes with followups below, but my inclination now is to merge this and take smaller incremental PRs to continue improving 😁

[Zac-HD]

thoughts for later

• we could test that this interface stays in sync with the Python definition
• actually, since we're writing to a database, if it ever changes (likely!) we'd better be prepared to read older and perhaps newer versions...

[Zac-HD]

Soon! (not in this PR though, it's already Large)

[Zac-HD]

Noting for the future: some users will want to self-host this; so we'll eventually need a corresponding config option. (I don't think we can ship it, since the webapp is not open source)

[Zac-HD]

Random notes from playing around with this:

• obviously we'll want to use the ✨new pubsub db feature✨
• zoomable / selectable graphs are pretty important
• it'd be cool if clicking on a line on the graph took you to that test's page
• the patches page says "waiting"; something like "no failing examples yet, so no patches either" might be clearer
• in the minimal failing examples, I noticed that for tests using st.data() the interactive draws weren't printed
  • and as a more general principle, I think we should discard textually-identical entries in the list, since they're ~useless to the end user
• I'd love to get a live/interactive demo on the website, and iirc we chatted about doing this by having the frontend consume data from either the python backend or a static json blob (with timing metadata?). They say you can solve (or at least move) almost any problem by adding another layer of abstraction...
• maybe we should be running ts tooling in CI? e.g. prettier for formatting? Plus updating pinned deps. IDK, not an ecosystem I'm familiar with.

[Liam-DeVoe]

lots of good stuff in that list, will work through it 👍. Brief notes:

• +1 for prettier, just wanted to leave tooling for a higher scrutiny review
• clicking on a graph line should already work (but hover tooltip ux needs work)