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?
@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.
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?
