Yea I’m no longer interested in exploring web components further, I’m actually ready to start building them IN a builder… natively, or really close to it.
My original post, in short, was about me trying to bring components AND nested components into Bricks… IF bricks doesn’t see the need to do it.
1 Like
This is something that has been missing from page builders for ages, and I’ve been dreaming about getting it added. Here is my ideal solution:
Components would allow you to set properties based on field types such as:
- Text
- Number
- Image
- True/False
- Another component (maybe I’m dreaming, here
) - etc…
These fields would need to be type-safe, so users don’t put in a string (text) where a number should be, for example.
You should be able to:
- Set a default value for each property in the case where no value is set.
- Use these properties in:
-
Fields - (eg: set
{name}to “John”) -
Conditions - (eg: show element if
{stars}> 3) -
Custom CSS - (eg. set border-radius:
{10}em) -
PHP code blocks - (eg: <?php echo
$name;> ) - Query loops - (if the component contains a query loop, we can pass the property down to the query)
-
Fields - (eg: set
Also, it might be useful to pass on additional CSS classes using props
4 Likes
I don’t understand why it matters who is voting? Surely you aren’t suggesting that some peoples votes should count for more than others?
To follow up on my previous post … here is the Gutenberg version of this concept. They are exploring it as “partially synced Patterns”:
2 Likes
Yes, and no. The vast majority of users don’t even bother to go through the forums, and will just use what is made available. I think the users that really “understand” the builder, love it, and promote it, somehow are the pillars of this community. The fact that we are discussing this here shows we have dedication and care about the direction the builder will take.
5 Likes
Dynamic Global Components is more than just about changing the properties of the HTML tags and elements/widgets along with dynamic data/text/media so in that instance of its use the differences are remembered.
It’s also about the ability to adding or removing additional HTML tags and elements/widgets.
Basically, ANYTHING added/deleted/modified needs to be remembered for that instance of the component while the rest of the component still reflects the global part of the component.
4 Likes
Bricks Team,
Please make this a priority and get it done as soon as possible.
2 Likes
I think you’re reading more into the one sentence I wrote, than what was meant.
So to be clear, here’s an example… as of right now there are 3,904 up votes for custom shape dividers
And it’s already on the Planned stage. Roadmap – Bricks
If you are a web ‘designer’, I get it. But if you are a web ‘developer’, something cosmetic like that (which can be done without bricks providing it natively) does not even register when talking about (the functionality discussion in this thread) is arguably the most needed feature / functionality in Bricks, and IMO in all builders.
The need for a Back To Top Element vs the need for this functionality discussed here, if you’re a developer is not even a discussion.
Not trying to shame or belittle ‘designers’ vs ‘developers’, but when talking about the future of a major tool used in your ‘business’, your ‘agency’, your ‘development stack’… this particular functionality is paramount over Custom Shape Dividers or Lotties or Back To Top Element Roadmap – Bricks!
Albeit, we have kinda hijacked the actual title, “Gloabal Components…” lol.
Which is why I said the ‘number’ of up votes isn’t indicative of 'who’ is voting, when it comes to this very functionality discussed here.
7 Likes
Read this topic, don’t forget to vote for it 
Let’s see who is more here, developers or designers 
2 Likes
4 Likes
This is the second follow-up regarding “partially synced Patterns” in Gutenberg. They have two remaining concepts — templates and patterns — having recently opted to rebrand reusable blocks as synced patterns. They are well aware that template parts closely resemble synced patterns, and they’re actively working on unifying these two ideas as well. This streamlined terminology, I believe, will be beneficial for them. In any case, this follow-up confirms the eminent introduction of “partially synced Patterns” to Gutenberg, as revealed in a teaser I received from Matías Ventura:
https://twitter.com/matias_ventura/status/1682418722206523392?s=46&t=lICylazxGcNzma33ImlcNQ
2 Likes
I’m adding my voice to the “yes we need this” group.
At a fundamental level, I feel like this could be simpler than people are imagining.
All we’re talking about is merging properties right? You have the global template (i.e. component), and you have a unique instance of it added to the canvas.
Now in the canvas you can change anything like you normally would, but anything you don’t change gets inherited from the master.
It’s like, you merge two property sets where the instance overwrites the master.
Since the master is a dangerous thing to mess with, I would be fine making the editing of that an extra click or two or a separate interface, because it really shouldn’t change much, and we want to protect end users from accidentally doing global edits verses instance edits.
I know there are a zillion little details in there regarding how to overwrite things like custom code or custom CSS, inheriting and overwriting dynamic properties and data, how to handle if entire sub-elements are added or removed, user permissions.
The workflow of not having these types of components is that we end up trying to create it manually through our CSS classes, custom shortcodes, code blocks. But really who has time for that? Instead we copy elements and structures and change them (or not), and hope we don’t some day need to make a global change to all the copies.
Other builders are quickly figuring out how to get this done, but I also know a lot of builders don’t have it (chump consumer builders).
I once needed to update a “footer” only to realize this was WPBakery and the developer had inserted the footer as a unique thing within every page! I had to edit every single page of the site to make updates to the footer because they didn’t use some kind of global footer template.
Any time we need to make something “global” but can’t, and have to edit every copy, well that makes us chumps. And we cannot be chumps!
2 Likes
I’m fully aware of that already was a part of the live discussion. Actually my comment is the latest one under the video.
But that’s not what we are discussing here. He was discussing how to accomplish some templates / component things as Bricks ALREADY has them implemented. . AND that video requires Frames, while we here (in this discussion) are discussing NATIVE functionality in Bricks… Two entirely different things.
Now if you wanna refer to some actual components that @digitalgravy and his team have gotten done the right way, meaning look at the controls… all done in right in the builder / canvas… no clicking and settings in all these weird places, etc. Just simple settings… nothing to figure out… no buggy code on the frontend, no locked in pre-designed ‘element’… and it just works.
Then maybe have a look at:
One click FAQ schema! mainEntity acceptedAnswer etc already done for you (check with inspector), is crazy!
The modal… for example, being able to create a nav menu inside of it right in the canvas area with the controls right there without all of these settings all over the place, and then it just works.
TFar easier to do a ‘creative’ nav menu with the things you want in it, dynamic data, your fine tuned CSS, truly responsive, no need to click through numerous panels searching for what setting controls what item.
1 Like
The previous post doesn’t quite align with the original topic of this thread. To clarify, Geary refers to structures enabled by BEM (Block, Element, Modifier methodology) as local components. However, as this terminology isn’t universally recognized, this feature request (as I understand it) is more akin to forming a “ground truth” from any set of Brick elements, then repurposing them while revealing specific attributes.
Additionally, there seems to be a demand for a ‘diff’ type approach similar to those found in Adobe XD or other design tools. While this might be appealing to some developers or a designer demographic (working with this methology), it may become overwhelming due to the proliferation of properties caused by each variation. I personally favor a model where only certain properties are explicitly enabled.
However, the intent of this thread is to assess user preferences and experiences, making it a valuable resource. In the context of Gutenberg, the upcoming partially synced Patterns expose certain block controls. Interestingly, the exposed property only links back to the original control externally, thus utilizing all the inherent validation and functionalities of the internal control. A interesting strategy to consider.
2 Likes
We seem to be getting a bit off track…
By the way I notice that the Webflow video above is no longer available since they have a new one now. Here it is:
A decent explanation of what I think most of us want. With Webflow components you can also add html elements, interactions, etc… as well to unique instances which the video does not go into (it only talks about modifying text in an instance).
Cwicly also has a video about their upcoming Dynamic Global Components (or whatever we want to call them). I haven’t watch this video about it yet so I am not sure on if their implementation is any good.
With a few builders now implementing global components hopefully Bricks can learn from the other builder’s mistakes and take the best parts and eventually have the best implmentation of a Global Component.
7 Likes
Exactly 
This discussion thread serves as a perfect illustration of the divergent naming conventions used by builders and designers. Establishing a consistent, effective naming schema will be an integral part of successfully implementing this conceptually.
1 Like
Agreed 100%… no 1000%. My touch on Geary’s method wasn’t meant to be my sole argument. I was just touching on his method partly in reference to the response to @rmshare. Geary even clarified it to me directly under his announcement video that his tools are NOT meant to be actual ‘builder’ components. Initially I was expecting actual ‘components’ and ‘dynamic templates’ from his tools and after he clarified it… it then made sense to me. because I was expecting parameters… nestable components, etc.
But you’re right, like I said in that response above, the title of this thread and the ongoing discussion here is actually two different things. Probably should be a different thread.
I follow you and your posts here and other places as well, ala BricksForge. I see that you REALLY have an understanding about how all of this works, so… let me toss this at you and tell me if you think it is practical.
And ofcourse I’m talking about a very basic ‘starting point’ for real components in Bricks… what about if Bricks had a really simple API for constructing atleast a basic component (beta). Which we could then use json object with key:value pairs like:
(to keep it simple a button, but NOT the bricks button element… my own button)
{
"text" : {
"label" : "Text",
"type" : "text",
"initial" : "My Button"
},
"href" : {
"label" : "My Link",
"type" : "text",
"initial" : "https://somewhere.com"
}
and so on - parameters
}
Being able to create our own json for use with API would even give us the ability to have our own controls, properties and inputs right in the builder!
I know for Bricks devs this would be a major undertaking… but IMO, this is what these builders are missing.
This is @Tom’s feature request, so let’s stay focused on the topic. I mentioned the upcoming Gutenberg implementation for comparison, highlighting the differences in people’s understanding of what a component is. If you’re interested in a semi guided text-based solution, there’s already a tool available for purchase by @Daniele that helps you program and create custom Bricks elements. However, to compete effectively with the upcoming solutions in the ecosystem, this feature needs to be visual and offer a no-code solution. Hopefully, the Bricks team has seen the thread and will consider the feedback provided. With their expertise, they might come up with a fantastic solution in the future. Fingers crossed for something great from them!
I can’t imagine Bricks not adding this. I think it’s only a question of time. And as far as I know @thomas, it will be done properly.
4 Likes
Do you care to share what this tool is?