Code review: headless, virtualized Dioxus table library

Hi all!

I will be up front with you all, I am not a Rust developer. However, I have been honing my skills working with AI agents to work on the code writing, with very specific and thorough architectural boundary rules. I developed this robust system utilizing a language I do know (TypeScript) and I wanted to run an experiment. This experiment was basically: is my process well-defined enough that it works in a language I don't actually know?

Background: I have become interested in Rust because I wanted to take a look at coding languages that are far more efficient than ones like JavaScript or Python. To further this, I am looking to port a TypeScript side project of mine into full stack Rust, using Dioxus for the frontend. Furthermore, this UI needs a table library (currently using AG grid in the TypeScript code). I figured that I would try writing my own table library in Rust using the aforementioned process I've created to force-multiply using AI. I am aware a few already exist, but I wanted to try to create my own, specifically one that supported Dioxus integration and virtualization, which I could not find an existing alternative for, among the options.

The agents ran some investigative routines before reporting to me the findings of the Rust standards and tradeoffs. After investigating these one by one I created a set of instructions for it to follow in creating this library. And after development and regression testing, I will say that it appears to be working fully as I intended it to, unit tests and all. However, I am well aware of the gap of simply trusting output code without knowing the language, so I am asking if anyone in this domain could review the output Rust and ensure that a couple of things hold:

  • Is the error handling and layer separation idiomatic?

  • The implementation chose the `Arc<dyn Fn(&Row) -> CellValue>` accessor pattern, is this the right call?

  • Does the virtualization approach look sound?

  • Are there API ergonomics that would feel un-Rusty to a native?

I found one limitation I deferred, the data pipeline recomputes per render on scroll rather than memoizing on scroll-only changes, would love thoughts on whether deferring that is sound.

I do intend to learn Rust more myself, once I have the time. The scope for this though, was the experiment, not my skills in the syntax.

I invite brutal feedback on this code. Thank you!

Github repository: GitHub - zernst3/rust-chorale: A headless, type-safe table library for Rust with adapters for Dioxus and other frameworks. TanStack Table for Rust. ยท GitHub

What does the project do?

I was lost at "headless". In my world a headless system has no display. Luckily the TanStack (which inspired this apparently) explains what a "headless UI" is, basically all the logic of some UI without the actual user interface. Now I don't know what this does and I don't know what TanStack does. Seems to be the guts of a spread sheet but without the rendering to display part.

It's an inappropriate request here to ask that others who know Rust review code written by an AI agent. This is a human-to-human forum.

Thank you so much I appreciate this feedback! I will make doc updates to be more clear on what everything is supposed to be.

And yes, you got that right. Headless in this context means that the root components are not framework-reliant. The core components live separately from the adapters that make them compatible with the frameworks.

As to what this is supposed to be: it is a frontend table library. So you are on the right track with the spreadsheet idea. It is meant to display a table, with filter and sort options, among others. Besides TanStack, if you've ever worked in an org that uses AG Grid on the frontend, it is similar to that.

The headless nature means that it will be compatible with the major Rust frontend frameworks. Right now it works with Dioxus because that is the framework I in particular am working with, but I plan to add Leptos support as well!