I’ve known in the back of my head all along that, while there was a place for the multi-field form blocks I was building to capture things like customer names and addresses, the “pure” way of attacking my block-based application building project was to create a bunch of generic fields. This is what existing WordPress forms packages have done for years and it gives you more or less infinite flexibility.
Of course the situation with forms builders is a little different. They let you create forms and then the forms get dumped into an email or a per-form collection of data. You’re not really building an application, but rather a data collector, and something of a disconnected one.
What I knew I’d have to put together at some point was single fields that were not only Gutenberg blocks, but also fields that knew how to interact with each other. You can put any mixture of these fields anywhere you like on a page, drag a “submit” button out there to join them, and then all the collected data needs to be submitted to the correct parts of the underlying database.
Because, yes, there’s an underlying database. This is what gives you the magic application-building capabilities. And it means you aren’t just piling up disconnected data form entries, but that the data winds up in a relationship to all the other data you’ve collected.
I’ve built a couple of prototype single-field blocks in the past couple of weeks and, honestly, it’s cooler than I thought it would be. That’s because I’m free to use React components on the front end. I’m using a library of components from a company called MUI, and their stuff is just prettier and more versatile than you’re out-of-the-box HTML form elements. I’m not saying it’s not doing pretty much the same stuff, but there are all sorts of small flourishes that I frankly just plain love.
While these collections of fields do operate in the same basic way that forms do, there are some differences (in a good way). For one thing, you can collect data that’s headed off to different data tables in the same form and it’s completely seamless from the user point of view (actually from the designer’s point of view as well–you don’t have to do anything for it to work).
Since all these components use a REST API to talk to the WordPress backend, each field can, if it needs to, validate the input to a field by sending the proposed data input to the server to be looked at. So, to take a somewhat contrived example, normal client-side vetting for an email address just checks to make sure the basic format is right (there’s an @ character, there’s a .com or .whatever). But you could, if you wanted, send the email back to the server, which could ping the mail server to make sure it was really there. Not saying this is generally worth the trouble, but it’s nice to know you have the option to do some actual sanity checking as you validate field input.
I’m not quite sure when the individual field blocks will be ready for release, but I’ve been surprised by how well some of the trickier-seeming parts of this have been going, so I think we’re talking a small number of weeks. It’ll be pretty groovy to roll this stuff out.