First look an issues with 2.0RC2 Components

Feature Requests / Improvements
1

Hey guys. My first look at Components in 2.0. They are way better than in V1, but still room for improvement.
The first issue I struck (unrelated), you can no longer edit class names inline ??

Component Properties have limited connection to UI inputs and cannot be accessed in CSS. This means that most variations have to be done with class variations.

Also, in the builder when you attach variation classes through a property, the builder loads them in the wrong order, but it works properly on the frontend. So to work in the builder we would need to increase specificity of the variations.

Also when editing a Component with connected Classes, UI interferes with the class dropdown.

1 Like
2

for changing class names, it’s now in the dropdown with the copy/reset etc options


SCR-20250714-mnyg
SCR-20250714-mnyg1111×787 36 KB

3

Thanks David.
An odd bug. I was not getting that. I disabled Advanced Themer and got the option. Re-enabled AT and the option is still there.

4

Reg. what you were talking about in the video with properties being for style/css settings. Obv I can’t speak for the Bricks team, but I can’t imagine this’ll be included with their components feature. I think the ability to change classes per instance will be the way to do what you’re trying to do (for changing styles per instance).

If you think about it, for each instance of the component, you are able to change the HTML through properties
 the HTML tag, the content, attributes/classes & the configuration (when it comes to things like sliders, which really is just changing the attribute values).

But with CSS, it’s per page. You can’t make a CSS rule apply to only one instance of a component, unless it has different markup to be able to target it separately with a different selector.

In your example, trying to add a gap property to the element with the ID ‘brxe-baocpx’ what would you expect that to look like in the final CSS if you were able to populate with the property and had two different instances of the same component, with different values for the gap?

Without any different classes or changes to the markup
 it would just be overridden as the selector would be the same for each


/* first instance */
.brxe-baocpx {
  gap: 0.2em;
}

/* second instance */
.brxe-baocpx {
  gap: 0.4em;
}

(classes used because ID’s are removed in components)

I can’t imagine what the expected result would be. Bricks could do something like automatically add a component instance ID to every element as another class, and join the classes
 something like


.brxe-baocpx.fjhvsa {
  gap: 0.2em;
}

.brxe-baocpx.rjsfsjf {
  gap: 0.4em;
}

But then we’re back to class chaining.

it’s the same issue with the accent color variable example, what selector/rule would you be expecting to see in the stylesheet for the page if you had been able to use the ‘primary’ accent color property in your CSS for that element ID? How would it be applied to only that one instance?

edit - I guess a component attribute could work


:where([data-comp-instance="fjhvsa"]).brxe-baocpx {
  gap: 0.2em;
}

:where([data-comp-instance="rjsfsjf"]).brxe-baocpx {
  gap: 0.4em;
}

Just thinking through the idea out loud :slight_smile: Just not currently sure it’s a good idea when classes / scoped vars already do the trick of scoping styles. Happy to be convinced otherwise though.

5

Thanks for your consideration, David.

What is wrong with having a unique ID for each component?
The rules applied to the ID of the Component could be transposed to the instance unique ID of each Component.

Then instead of needing a variation class for every combination you could change a single property with. E.g. if you just want to change font-size using a select with Small, Medium,Large labels. The option values could be applied directly to the font-size input.

6

“What is wrong with having a unique ID for each component?”

Ah ok, so if you had a block > h1


<div class="brxe-moondt brxe-block">
  <h1 class="brxe-zpmcrx brxe-heading">My Heading</h1>
</div>

And you turned that into a component, you’re thinking the elements should be given their own unique IDs, to make sure it’s different per instance?

<div id="brxe-gkjdd"class="brxe-moondt brxe-block">
  <h1 id="brxe-sjedq" class="brxe-zpmcrx brxe-heading">My Heading</h1>
</div>
<div id="brxe-thlfhs" class="brxe-moondt brxe-block">
  <h1 id="brxe-mfnsg" class="brxe-zpmcrx brxe-heading">My Heading</h1>
</div>

Actually, I guess it would be better as a class, to avoid issues with loops


<div class="brxe-moondt brxe-gkjdd brxe-block">
  <h1 class="brxe-zpmcrx brxe-sjedq  brxe-heading">My Heading</h1>
</div>
<div class="brxe-moondt brxe-thlfhs brxe-block">
  <h1 class="brxe-zpmcrx brxe-mfnsg brxe-heading">My Heading</h1>
</div>

Then as you add styles via properties, they’re actually being applied to those unique ‘instance specific IDs’ not Bricks’ regular element IDs that would be the same. So you’d have something like


/* styles to apply to all instances */
.brxe-moondt {
  font-size: var(--my-component-font-size);
}

/* styles specifically added via component property */
.brxe-gkjdd {
  font-size: var(--my-instance-specific-font-size);
}

It could work well. I can definitely see how it’d be really useful from the UX perspective in the builder, it’s essentially the same as manually adding a new class to add the new rule, but just Bricks would be automating that part with a new random ID.

7

:slight_smile: Yeah. The is how I assumed it would work.

What I most love about Bricks is its flexibility. Components current appear to be less flexible than other areas of Bricks. Hopefully this will be considered.

I have to say that what I have seen in Etch for example, Components are way more flexible.

8

Yes I think the components feature is definitely not in it’s final form yet. For example, component slots also looks like it’s currently WIP, which will really open things up (adding different elements per instance).

9

I just added a bug report. Using a Toggle property to manage “Visibility” doesn’t work in the editor and has the reverse logic in the frontend. So currently our only reliable way to manage component state is with variation classes :slight_smile: