Using log1x/acf-composer for acf blocks means tight coupling with sage and blade templating for blocks no?

Im just new to learning gutenberg blocks, naturally most YouTube tutorials are for creating native react based blocks, so i saw barrier to entry was much lower if I used acf blocks instead. It looks like acf blocks are now trying to match the native wordpress block creation by using block.json to define configurations for each block. in fact some tutorials i have come across even use @wordpress/create-block with acf to create blocks.

If you were to create blocks using block.json and acf without log1x/acf-composer , you could then re-use your blocks in different wordpress themes as they are not tightly coupled to sage and blade.

So my question would be, what is the advantage of using log1x/acf-composer if you cant re-use the blocks in different themes?

There isn’t an advantage. ACF Composer merely provides an opinionated improved developer experience. It’s up to you to weigh the benefits.

The advantage for me are:

  • Auto syncing among the various environments. (No need to go into environments database and click sync or whatever the command is)
  • Not having to hop between custom field GUI and the text editor. This sounds small but makes for a much better workflow.
  • Users with Admin-level access cannot accidentally or intentionally edit custom fields.

@Log1x Thanks for creating acf-composer, Poet and Navi. I’m using Navi and its great. I guess that’s what I’m trying to figure out, trying to weight the benefits.

@rguttersohn For your last two points, couldnt you still just use ACF Builder for this?

Can you expand on the Auto syncing ?

Is there future improvements for ACF Composer to move towards block.json config ?

I’ve pondered with the idea of what block.json integration would look like but there’s no active development at the moment.

Right now, you’re not really missing out on any benefits compared to using block.json and it would only add unnecessary complexity to the ACF Composer workflow.

That being said, obviously I can’t ignore it forever and at some point I’m sure something will change that will make block.json a necessity. The idea of being able to cache blocks and with that auto-generating the block.json will probably be the first thing I experiment with.

Thanks for the reply. It lists a benefit of " The frontend CSS and JavaScript assets listed in the style or script properties will only be enqueued when the block is present on the page, resulting in reduced page sizes." I haven’t really used acf-composer enough yet apart from example blocks to know this so excuse me if this is a stupid question, but are all the JS and CSS scripts bundled using bud? so if a page lets say has 0 blocks on it, those assets are still loaded?

You can use the enqueue() method to enqueue styles/scripts as needed.

1 Like

Thanks for letting me know :slight_smile: