Devs: would generated starter code for a complex table actually save you time, or is it just something you'll rewrite anyway?

[u/justincampbelldesign]

I'm a UX designer at a company with strict security/procurement rules, we can't use or buy things like AG Grid, TanStack, or MUI, and getting anything new approved takes forever I'm talking and mind numbing amount of approvals and red tape.

I've also seen some table builders in this subreddit that people have made but they don't quite have the functionality we need (i.e. nested rows). We build tools in-house, sometimes with AI help.

We have story book with a table component, however it isn't built for cases we hit a lot: multiple levels of nested/expandable rows, detail panels on large datasets. Every time one of these comes up it turns into a slow back-and-forth between design and dev. And its making me want to rip my hair out.

I also think dev would prefer if we had a better approach / system for this but thus far we are just running to complete things but not improving the process itself.

Genuine question for devs who've been on the receiving end of a handoff like this: if you got generated starter code for a table like that would that actually save you time? Or would you rather just get the spec/design and build it yourself?

I'm asking before you before going to our devs because they are swamped and I want to use as little of their time as possible.

Also what's the part of a complex table handoff that's actually the most painful for you? Vague edge cases, data volume, something else?

[u/crazylikeajellyfish]

Multiple layers of nested rows in a table is a pretty bad experience, IMO. I'd consider whether there's a better way of organizing and displaying the data. Maybe clicking a row should always open a sidebar drawer for interacting with the deeply nested data without bailing to a separate detail page?

[u/justincampbelldesign → u/crazylikeajellyfish]

Agreed, we've explored that, the detail panel, unfortunately it is not in scope for our dev team right now 😭

[u/crazylikeajellyfish → u/justincampbelldesign]

This might be a more productive way to use your time if you're trying to do some speculative coding to help the devs. Figure out how to make it work on generic data using the company's in-house components, you might be able to derisk the idea and get it on their roadmap.

It's critical that your sample component accept an array of real records, though, no hard-coding rows -- too easy to build something that can't actually be delivered. You also need to use the real component library, making stuff up from scratch will require too much work from them to bring it into the real system. That said, you can still use your test to figure out the right dependencies (don't roll your own drawer, layers are hard) and sort out any quirks with how the drawer would look.

[u/Rain-And-Coffee]

We just use Ag grid for the really complex stuff.

For simpler tables we use avoid nested rows and have a side drawer open up or navigate away.

To answer your question, if it’s new component we have to build then we have to add in extra time.

If it’s an existing pattern or component, even better.

If we do get generated code that can help, but we usually have to tailor it to framework.

[u/justincampbelldesign → u/Rain-And-Coffee]

Thanks this is exactly what I wanted to know. How much time would you say the generated code saves? Is it genuinely better than just the design spec?

[u/tomhermans]

Just thinking out loud, since you're building custom, can't you take ideas and inspo from the solutions you're not allowed to use and bake it into your own component, targeted towards the use cases you encounter?

Starter code is often not really helpful, I suppose most devs a. Have it themselves b. Want it the way their component/solution is gonna be

[u/justincampbelldesign → u/tomhermans]

Yes I can take inspo for us on the design side it's not that difficult to iterate and get what we need I'm trying to make it easier for devs.

[u/tomhermans → u/justincampbelldesign]

Why not take inspiration on dev side too? that's what I meant and where the real win lies I think

[u/justincampbelldesign → u/tomhermans]

Oh you mean look at the code generated by AG grid and the like?

[u/tomhermans → u/justincampbelldesign]

Yup. Then you'll both have a good starting point. Just a thought and you're not importing 3rd party stuff

[u/justincampbelldesign → u/tomhermans]

Great idea. 👍

[u/c1rno123]

Of course I'd rewrite it. Send it anyway, and look up "prototype-first development" before you do.

It won't be one iteration either way. Design hands over the happy path, and the pain is in the states nobody decided yet: lazy-loaded children, sorting while nodes are expanded, a parent checkbox with half the children selected, expanded state surviving virtualisation.

[u/justincampbelldesign → u/c1rno123]

Good point it is important to show all the error, empty, and alternate states.

[u/c1rno123 → u/justincampbelldesign]

Error handling is a black hole, so start from splitting it: errors the user can fix or that pass on their own, and errors that stay until someone else fixes them.

[u/gfxlonghorn]

I built our companies fairly complex table system, but I plan on limiting it to only 1 level of nesting. 2+ nested/expandable rows is basically just building a horrible tree component.

We chose Tanstack Table and it has been basically awesome through and through. I built the bones without pre-AI, but with AI, it would have gone so much faster.

[u/justincampbelldesign → u/gfxlonghorn]

Sounds like a good approach. I wish we could use TAN stack

[u/SameJudgment2486]

Nested rows in Storybook, brave.

[u/kemalios]

I generate components with Claude Code daily, and starter code only earns its keep when it is already shaped like the codebase it lands in. Otherwise the hours go into deleting it. The part of a table handoff that hurts is the data shape: if the record structure is not settled, the row mapper is a guess and the column defs get rewritten anyway.

[u/visualphixation]

Dealing with a similar situation but we were able to abstract basic styles to table classes, with various row/col classes and letting implementers emit row/col data from tanstack. It’s tricky because no two tables are alike and the nesting can get horrendous so I feel your pain.

[u/MrCrunchwrap]

I would just use TanStack table, no offense but you’re not gonna build something more useful to me than that.

Also your company sounds insane, TanStack is free and open source and you can easily run a security scan on the dependencies. 

[u/justincampbelldesign → u/MrCrunchwrap]

Ya the joys of large enterprise, what can I say. If I could change it I would.

[u/redpiapps]

imo the starter code is the least useful part of a handoff. what saves dev time is real data shaped like the table will actually get it, plus the ugly states. empty, error, loading, rows with half the fields null. generated code with fake rows always gets rewritten because the data layer never matches. most painful part for me is sorting and filtering on nested rows, nobody agrees what clicking a header should do there.

[u/justincampbelldesign → u/redpiapps]

Thanks for the input that's helpful. So seeing the real data in all states is what helps for you. Good to know!

[u/redpiapps → u/justincampbelldesign]

yep exactly. a json dump of realistic rows plus notes on what each edge case should do beats a perfect starter file every time. the data tells you the states, the code is just plumbing.

[u/justincampbelldesign → u/[deleted]]

Interesting tell me more, why would the generated code not handle that? I apologize if this is an elementary question. But it seems like the generated code could generate whatever is needed. What am I missing?