Advanced Table fieldtype prototype for Statamic

It’s not the first time I’ve needed something like this - but for the scale of the site, it’s the first time I needed an Advanced Table builder for Statamic that works just like a block within an Entry - i.e. fields, and not relating to other Entries within the platform.

For example a comparison table which has 2-3 columns, plus row headings, and an unknown number of rows (and unknown row titles/headings). Such as this:

Within the Bard field, you can create Tables, but the issue here is that they’re just that: tables. And we all know tables for layout is bad. But also if we want that data for a mobile view (that is not a table), we’re out of luck.

So I started playing with the idea of an Advanced Table fieldtype for Statamic - and turns out something is feasible. Not sure how “together” this is, but it does work and ticks the box for this current client.

For this project, the table needs to have 2 (or sometimes 3) columns, with a heading consisting of an image and some text.

The table needs to have any number of rows, and the row headings could be anything: they’re not standard across the site.

The content for each cell needs to be Bard, with easily linking to Entries within the site.

The data is needed for a desktop table display (like above) as well as a collapsed mobile display - so not just a “table”.

And it all needs to be easily editable by someone without a tech degree.

While Statamic’s Blueprints can offer most of this functionality, we can’t easily have one field populating options for another field within a replicator inside a replicator. Yeah, nested. It needs a bit more of a custom approach.

Can this be done as a fieldtype, that hooks in and re-uses existing Statamic fieldtype components?

It turns out, yes it can.

But I’ll admit the code feels rough, and a few things don’t quite make sense (even though they work). Validation (and nested validation) was unnecessarily tricky, and debugging a little unpredictable. But it works.

Let’s take a look:

Let’s take a closer look at the logic here.

First of all, we need to populate the Rows - this is with a simple List fieldtype within Statamic. This List does a few things:

1. Shows the Rows in the order the author wants them to appear

2. Is used to populate the Row Headings for each Column’s Row

Secondly, we need to add some Columns. Each Column has an Image, Text and one or more Rows.

The Image and Text are straight forward - but for the Rows, we have an internal array structure where each Row has a Select and a Bard field.

The Select field’s config is hydrated with the Options generated by the Row List from earlier. And I’ve even made it so that when you change a List item, any references to that item in a Column’s Rows gets updated too.

All of this saves nicely, and can be edited again too (of course this is obviously critically important).

The final piece is the augmentation from the stored structure to something we can use in Antlers.

This has a few things to consider, including:

• accessing data row-by-row,

• accessing data for a specific column, and

• ensuring that no matter which way we go, we have a complete view of the entire table

That last point is key.

So let’s say you have 3 Rows, and Column 1 uses Rows 1-3, but Column 2 has only had 2-3 added.

When looping through the stored Rows (raw, by default), our data for Column 2 would be incorrect as it would put 2’s data in the cell for 1, and 3’s data in the cell for 2 (because we are missing a Row 1 reference).

This means that the data needs to be made in to a perfect matrix, including gaps for any missing data.

The augmentation for the fieldtype does this, and splits it in to easy access for both row-by-row and column-then-row looping, making it super simple to use in Antlers.

It sounds simple when it is all written out but it is a bit of a beast of a banana fieldtype. I’ll be putting it through its paces over the course of this project, and figure out what the next steps are.

And what to do with it.

It’s highly opinionated with what fields it includes - so isn’t ready for just anyone to use. But could be with some more work.

I’d also love to have the pros at Statamic work with me to polish it up a bit more: this level of advanced fieldtype creation was a little undocumented so I’m not really sure if it is the best way to tackle things. And there are more points that could be refactored too.

Maybe it has a future as a core Statamic fieldtype. Maybe it will be a third-party addon. I do feel that this is a neat way to allow an author to create an advanced table though.

What do you think? Let me know!