Builder Component Augmentation

[Jubeki]

The Problem explained

Currently if you create a Builder component, you can use different types of blocks to compose e.g. a page builder.

If you want to change the schema of one block, you begin encountering problems. This is due to the fact, that the schema was updated and can be used while creating and editing, but already existing data is not updated to the new schema and the new default values are not present.

This results in a problem, that you have to constantly use $data['newVariable'] ?? null to avoid errors.

A possible solution

Similiar to the Blueprints in Statamic, you could use augmentations to transform the data using the schema before passing it to the view, you could go even further and render the whole builder component using the provided configuration, instead of manually building the rendering.

How would this work?

1. We would need new methods, to define the view that is to be rendered for a specific block type (similiar to the preview feature: https://filamentphp.com/docs/3.x/forms/fields/builder#previewing-blocks)

2. Then there is an augmentation method, which is called with the data for mutation/transformation and returned as an array. There should also be a augmentedRender method, which renders the view with the augmented data.

What more can we do?

Augmented Migrations: We could also use the schema to migrate the data stored in the database. For example add new default values to existing data or delete non existing fields.

Store related models: We could use a Morph-Many relationship to store related models to the whole model, so that we can fetch them without having an n+1 query issue. Currently if you want to fetch related models, you would fetch them for each field in each block individually. Using augmentation you can first fetch all related models and then map them to the corresponding fields in the blocks. (one most used example is spatie/media-library)

Storing the data in a relationship instead of a json-column (the relationship table would need a type and data column): An advantage of this would be for larger page-builders, that store maybe many blocks with different fields for translation and reaching the limit of the text column (which is 64 kB, there is also mediumtext 4 MB and longtext 4 GB which can be used, but can be overkill). You could also link to existing blocks, so that you can re-use them on different pages.

Conclusion

What to you think of these ideas?

My plan would be to create a PR for this for filament v4.