The case for Block Bindings API vs Custom Blocks
Whether you’re migrating content from ACF to blocks or you’re doing something like messing with the Events Plugin and need to show some ACF data, you have two options:
- Write a custom dynamic block
- Use the block bindings api
The right option depends on what you need. Writing a custom block is well covered, so here’s a reason and quick tutorial for how/why you might reach for the block bindings api instead.
What is the Block Bindings API?
Once it’s all hooked up, the Block Bindings API is a UI-driven way to connect simple, supported blocks with some external data source (e.g. ACF fields stored in the postmeta table). This API is great for displaying custom data that you don’t need to write a bunch of extra controls for.
How much work is the API vs a Custom Block?
It kind of depends on your workflow, but here’s the overview:
Block Bindings API
If you’re using straight ACF data:
- Add the following:
add_filter('acf/settings/enable_datastore','__return_true'); - Turn on the “Allow Access to Value in Editor” toggle.
If you’re registering a custom source:
- Register a source via PHP (you could leave it at this)
- Register the source via JS for the block editor’s consumption (this is the bit that makes it UI-driven)
- Add the JS file to your webpack config
- Hook a compatible block up (via HTML if you skipped #2, or via clicking around)
Custom Block
- Maybe create a custom plugin? Or at least update your webpack config to handle blocks (if it’s not done already)
- Scaffold the block (dir, block.json, index.tsx, render.php, edit.tsx)
- Write the files
- Render the block