MWDelaney / sage-acf-wp-blocks

Composer library for generating ACF Gutenberg blocks from templates. Intended for use with Roots/Sage (http://roots.io)
346 stars 66 forks source link

Sage 9 - Enqueuing CSS and JS causes duplicates #62

Open da-kicks-87 opened 3 years ago

da-kicks-87 commented 3 years ago

In the block template files in the top comments, I have added the path for my main.css file for EnqueueStyle. I do this so I can see the preview of the block on in the WP Block Editor.

I use multiple SASS files that are compiled to main.css (each .sass file represents a block). This is common practice for SASS. When I use the browser inspector for the front website ,I see that the main.css is being enqueue for each Block I have on the page. This causes redundancy when using the the inspector when debugging the CSS.

Same issue I have with JS. I use my main.js to import other js files and I have Webpack compile it.

How do I get the block preview and not have duplicate CSS / JS enques when using SASS / Webpack?

twinleafdev commented 3 years ago

Having same issue. Any ideas?

twinleafdev commented 3 years ago

I ended up enqueueing the scripts for admin and not using the block template comments

add_action('admin_enqueue_scripts', function() { wp_enqueue_style('sage/main.css', asset_path('styles/main.css'), false, null); wp_enqueue_script('sage/main.js', asset_path('scripts/main.js'), ['jquery'], null, true); });

da-kicks-87 commented 3 years ago

I have tried that, it seems to be the step in the right direction but more CSS issues occur when doing do. Thea stylings from my custom color pallet variables get applied to my WP Dashboard options. So for example the list of Post Titles in Dashboard will be pink instead of blue.

The more I use ACF Blocks the more I see how unintuitive they are versus the native WP Blocks are. It weird having to switch view modes, can't directly edit when it in the visual preview mode, "Inner Blocks" is confusing for clients, inaccurate preview etc...

I think for future projects I will go back to ACF "Flexible Content" and "Repeater" fields...

robmeijerink commented 3 years ago

This field was not intended to put the main.css in, but rather seperate css files that only have css that this block should use. If you add multiple blocks of the same type, the assets will only load once. But if you use the same css file for different blocks, you will get duplicates.

I use this feature to include a css or js file that only has stuff the block needs, not to include the main.css here. Main.css should be your theme file, but not the block css file. Using one main.css file for all your css (including the block css) defeats the purpose of this field. (+ this is bad practice and decreases your pagespeed score)

twinleafdev commented 3 years ago

@da-kicks-87 I'm liking the custom blocks a lot more then repeater fields so far though I'm working on a fairly simple layout.

da-kicks-87 commented 3 years ago

@robmeijerink Thanks for this explanation.

But the main.css has global theme variables and styles that all the blocks would depend on for an accurate preview. The main.css would have to be loaded in some way. So how would one get around not duplicating that or causing conflict with the Dashboard CSS?