Came here to support the needed implementation of adding a connection to background images for components, but in general setting custom CSS property values may prove useful.
Having now rolled out our first large site using components I have some more thoughts on the image property.
Exposing the object position control mentioned above is absolutely essential. I donāt think this should be a separate text/value property that we can connect to the value in the components Image, I think it would be much better if we could turn on this field in the property settings. If we add extra value property fields rather than combining them into the actual property control then it will create a lot of extra UI for that component as thereās a lot of space between separate properties.
When used across a large number of pages, being able to set object position on images is crucial for certain designs to work properly at different screen sizes. Especially break points in and around tablet sizes.
In addition it would be REALLY helpful if we could also access the responsive image functionality so we could swap out an image at different sizes in the property set in the component. Again this really needs to be able to be turned on in the property as connecting multiple image properties to the various sizes is silly from a UI perspective and given that conditional logic doesnāt work at the moment would cause a lot of issues.
The two other properties it would be great to expose in this way would be aspect ratio and object fit.
We wouldnāt necessarily use them on all components but object position Iād use on 90% and Iād be happy to see that just added by default to be honest without an option to disable it.
I didnāt notice missing options on other property types at all but the image ones really required me to work hard to avoid pitfalls and required several versions of components to be created which slightly defeats the purpose.
3 Likes
Ok this is cool
description supports html and we can do cool stuff with it.
Embedding Tutorial Video inside Component Description 
In coming weeks and months I am getting ready for a very big client site build. I was thinking about variables and some classes but I think it is the time to use components
I will still need some variables but components almost eliminating my global classes needs
I was testing some random stuff and came up with this video desc
I think these type of tutorials are perfect since we dont have to create external tutorial page or documents both agency interns and/or clients can just dive in and start using components easily.
simple video html element in property desc thats it
Thereās no way to return the value of the property currently right? So we canāt put the values in things weād normally use ACF for? (i.e code blocks, image loops, grab image URLs from gallery property and assign then to individual image tags in the structure panel/post loop?)
Trying to use components for the first time instead of templates but they feel super limited still and like I need to use ACF a lot. Even things I am linking them to within filters in query loops are not returning the values as expected, unlike ACF or plain text do.
NO.
Components are not here to eliminate Custom Fields. We can use dynamic tags and get customfields with dynamic tags sure but That is not the problem components are solving.
Components are here for you to create a design/feature/section/block/loopitem just ones and use it multiple times/ multiple place/ multiple page and only edit or change ones globally almost like a Custom Element.
Sure, understood. But thereās education needed from Bricks I think for use cases for when youād use one over the other - i.e templates, ACF, Bricks editing itself, Components.
Iāve always used Templates and conditions, with ACF. This has never really felt limiting to me, other than like others have shown if you have an area or hero that you want to add a small HTML change to - classes alone wonāt do that so the component makes perfect sense.
Itās the addition of fields and encouraging use of the components to edit āsome thingsā - but then using ACF for others I think is where I struggle with the line on that. If I need to go to two places to edit things itās a bit sluggish and I might as well just use ACF with Bricksā conditions in templates.
Donāt use any ACF fielt when building a component and you are perfectly fine.
The connection to ACF is made on the instance, where you actually use the compenent. Then you have a indepently reusable component and no problems.
Yeah Iām probably not explaining myself well, sorry. Iāve been using components with ACF for instances and itās working fine.
I mean more when youād start using fields over properties, given the limitations of properties itās still largely easier to just manage most of it with ACF and conditions.
Ok now I am sure.
Atleast for layout elements we need nestable. Section, container, block and div.
Components have power to create better class based elements. Since every component creates classes instantly and because of that it has great power. every component instantly becomes global classes.
Definitly needed. This feature completes the components. it is that important.
semantic layout components examples;
section-s
section-m
section-xl
section-xxl
container-s
container-m
container-xl
container-xxl
imagine having these semantic nestable layout components and using them again and again. create ones use multiple times.
I find this type of global component/class management easier, simpler, cleaner and even less work then classesā¦
since we can export and import components this will become the new way of global class/component library for our workflows.
2 Likes
100% agree. Nestable components are definitely a must to create any sort of properly reusable complex layouts. Without nestability, components lack a core aspect of their appeal.
2 Likes
@robp The way I look at components in general is like pre-built elements.
So, instead of creating a custom accordion, card, or button with PHP to be accessed in the Bricks elements panel, I create a component.
The advantage is that if you ever want to recreate the design with modern HTML/CSS or change the layout, you simply recreate the design; the properties in the individual instances will remain as they were.
Then, on those individual pages, you decide whether you want to use ACF fields or static data, just as you have already been doing.
1 Like
Just to keep a note for nesting will drop this here.
3 Likes