Bloqs with Grids

Thursday, June 15th, 2017

TL;DR - There are no plans to add Grid or Matrix support to Bloqs, however, you can use Simple Grids & Tables inside of Bloqs.

There, now that we got that out of the way, lets talk about why. There are two main differentiators when it comes to ExpressionEngine fieldtype add-ons: those that save their data in the native exp_channel_data tables, and those that do not. When it comes to interroperability between add-ons this is usually the defining factor of makes them "play nice" with other fieldtype add-ons. When an add-on chooses to save its content in its own database table, usually a necessity driven by the fieldtypes complexity, it is removing itself from ExpressionEngine's sphere of knowledge (for the lack of a better term). EE knows about the add-on because it is installed, and the add-on can talk to EE because of the excellent code hooks and events that are in place in EE's core, but when it comes to saving and retrieving data (usually a channel entry), EE itself does not know how to query the data from a fieldtype that saves its content in a separate database table. The fieldtype add-on is soley responsible for doing that by using the hooks and events EE provides.

There are two native ExpressionEngine fieldtypes that save their data in tables other than the exp_channel_data table, and those are the Grid and Relationship fields. Third-party fieldtype add-ons like Bloqs, Matrix, Playa, Channel Images, Channel Videos etc also save their content in custom tables. Now imagine the scenario where two of those add-ons are designed to work together. Or more specifically where one of these add-ons lives inside of the other. Here is a common scenario:

Bloqs → Relationship

Managing Relationships inside of Bloqs (or Grid) isn't all that difficult. It takes some trickery to get it to work, but its managable. Now lets look at a more complicated scenario:

Bloqs → Grid → Relationship

If we introduce a Grid inside of a block, and that Grid can have 1 or more rows with a Relationship field, the complexity skyrockets. We're making sure data is passed correctly through 3 layers of add-on code, and into 3 or more database tables, and this is just for the data side of things. On the front-end, what if the related entry then contains its own Bloqs field, that in turn contains another Grid, which in turn contains yet another Relationship. 

Admittedly, this may be technically possible to pull off, but there is an important, and often overlooked aspect, of developing and releasing add-ons. Supporting add-ons is no small feat, especially when they are complicated, and are meant to work with other third-party add-ons. There will be bugs, and the more layers of complexity that are introduced the number of bugs will increase. While initially adding what seems like a simple feature may take only a few hours, or a few days, supporting that feature will last for the lifetime of that code.

Just because you can, doesn't mean you should.

Bloqs is a flexible page layout tool. It is not a way to present structured data to a user. Grid is inherently a structured data tool. You define criteria (e.g the columns) and add repeated instances of that data. As such, it is our opinion that structured data should not be managed in an unstructured tool such as Bloqs.

So what are the alternatives?

The easiest, and most stable way, to add a grid in a block is to create a separate ExpressionEngine channel to manage the grids, then use a Relationship field to assign that grid to a block. For example, a photo gallery is a very common use case for adding Grid support to Bloqs. But you could just as easily create a Galleries channel, then create an entry for each gallery, then assign that entry to a block with a Relationship field. In doing so, you're maintaining a more structured data set, and also able to re-use the gallery outside of Bloqs, or use the gallery again in different entry containing Bloqs. This may seem like a few extra steps to create a new channel, but in the long run your data is more normalized and more portable.