Started testing the components. First of all great work team well done
Time to polish this for prod use.
Feedback 1:
Image propery only connects to the Image element. (but image element is not the only place we can show images)
I build lots of image sections with background so I can put text or other elements top of the backgrounds. I think using css backgrounds very common I dont need to write much examples about this.
Image Property needs a possibility for connecting to Background Images.
Yes we want to lock the users for sizes, design decisions and styles when creating components. But I think we need one more property for some edge cases.
Value Property
With value property we ca nconnect the font-size, spacing, width or height for rare cases that we need to give control to the user.
Doesnt matter how PERFECT the components are clients always needs more control in some edge cases. I think Value Property and ability to connect to the most or even all css fields can solve this issue and gives us more freedom to create powerfull components.
Advance Dropdown Property for static select list and ability to connect anywhere text or image (and maybe values?)
just like form dropdown select field we can add only static options so user can select the existing texts or images.
last year we were giving some development support for one of the biggest german brands they were using adobe cloud sites on there they had lots of existing components some of the components didnt even have freedom to change texts because they have determined and finalized mottos, slogans, posters or brand titles…etc
when building pages we were only able to select existing assets for those components.
On enterprise level this is very common because changing one color or even one title on a page needs to be approved every time.
There’s a couple of things missing to take it to the next level.
A “value” field as you suggest will do a lot of heavy lifting. For example it’s quite common to have to override the top padding in a section to tweak space between elements. Having a value field would let you insert a default and then override it easily. That would let us use the same section component without having to make a second copy that has no padding at the top.
The ability to use the values in conditions for items in the component. If you were to combine that with a true/false toggle property field type and a select dropdown property field type you could do some amazing things that would be really client friendly.
Lastly it would be nice to have some organising in the component view - e.g. a button needs a link and text property - it would be nice to be able to visually link these and separate them from the other properties visually.
Agree with the suggestion for a ‘value’ field, or some way to expose settings for the style & layout properties.
I’ve installed it locally and started to work with the new components feature, which I’ve been very eager to use. My first thoughts:
The interface and workflow for editing are, on first pass, really beautifully designed and implemented. Creating, editing, and exposing properties was all absolutely seamless. Fantastic job here, Bricks team.
A few other features I would love to see implemented:
nested components: this one is big for me. A simple use case is creating a branded button with an icon and hover animation, and then nesting that into a card element… but many other & more complex use cases can be imagined for a fully components-based system
conditional elements which can be toggled on/off (might have missed this, still exploring)
My rant about components is that we can’t see an actual dynamic tag used for property.
For example, in JetEngine components when I create a property I got something like {je-component__my-property-name} and then I can include it wherever is dynamic data supported, and the most important in condition rules.
Bricks components are very limited at current state.
I am also unclear on the use case for nested components. This initial implementation is simple and clean. Fantastic that editing is done in situ. What is the value proposal for nested components (I worry about complexity for the sake of fun).
There are definitely a lot of use cases for nested components, and flexibility is key! They can make editor editing much smoother and more intuitive. Here’s an extreme example from a Webflow user that shows the potential: x.com.
