https://www.wp-monkey.com/bricks-widget-creator-for-wordpress/
1 Like
That Cwicly video is painfully slow… 30+ mins into the video and nothing but in / out of modify mode… move title above / below paragraph.
But it is clear to see they have managed to to allow the editor to construct components by using json object without giving the editor an API or API access. In a nutshell it’s the same thing as here:
{
"text" : {
"label" : "Text",
"type" : "text",
"initial" : "My Button"
},
"href" : {
"label" : "My Link",
"type" : "text",
"initial" : "https://somewhere.com"
}
and so on - parameters
}
But this Cwicly method is no api access, you create / map key:value json object in gutenberg.
1 Like
Just chiming in here with another vote for dynamic components!
Would be a game changer.
2 Likes
This would really revolutionize the way sites can be built in Bricks. Please also consider the way these items would be added to the canvas. Some type of keyboard shortcut, search and selection would make the process super fast.
3 Likes
Yes, we want dynamic components. Please make this a reality. Bricks is already awesome, but with this it would be the king 
5 Likes
We need this!!! 
I have been using dynamic global components in Figma for a long time, and can’t understand that we can’t follow the same approach in Bricks!
This is not a dev vs designer feature, like someone suggested. Both could infinitely benefit from this implementation, if done right!
C’mon @thomas! We know you will deliver!! 
7 Likes
Yes, both designers and developers would benefit, and also editors.
3 Likes
+1 for Bricks team to prioritize adding Components.
I just watched Kevin Gerry’s review of Cwicly’s global components (1.5 hours into his WDD Live video, link below). Very impressive, I can see how fundamentally useful components can be. Kevin also used Bricks to build something similar, and it was obvious where the downfalls in Bricks are.
@thomas , please take a look at the Cwickly components offering.
4 Likes
Not gonna lie, Kevin Geary’s recent videos inspired me to come here. Still, I’ve been using Components in Figma for a while, too, and I can absolutely see how having this in Bricks would make a huge difference in page builder land. I hope you guys are having an eye on this.
2 Likes
Despite the terminology differences, I think the general consensus being developed in this thread is absolutely right-on. We really need some method where we can:
- set up ad-hoc groups of elements
- set them as ‘global components’
- override settings & content as needed per-instance
- push changes from global components down to the instances, with instance settings & content taking precedent
- (optional) ability to customize which content/settings are ‘available’ for instances to edit
Bricks team, please consider balancing the ‘raw vote count’ of the idea board with the absolute business necessity for this kind of functionality. With Cwicly adding this feature, the movement becomes that much more imperative. Please don’t make me use a tool I can’t even pronounce
7 Likes
Pronounced as ‘quickly’, no?
1 Like
From a developer’s perspective, the term “component” is versatile, often referring to varied elements such as a function in code, a UI piece in web design, an element in Bricks, or a Gutenberg block. Therefore, simply labeling these as “components” might lead to confusion due to its broad usage. To enhance clarity, consider referring to these as “Design Components” or “Global Design Patterns”. These terms not only respect the diverse definitions of “components” across different contexts, but also emphasize their unique characteristics in our specific situation: grouped elements with design properties that are synced globally. This specific terminology provides a comprehensive understanding of their functionality and usage in my opinion.
2 Likes
There’s a survey that was posted on Facebook that might be a good place to voice opinions on the direction of Bricks as it refers to this feature and others.
5 Likes
I vote for this. I answered Global Components as the #1 missing feature in the Bricks survey. Because, I mean, it would be a massive time saver for all of us.
3 Likes
Hey everyone 
We appreciate everyone’s input on this feature request.
Some great points here that we can build upon and that will help shape this feature.
To address the elephant in the room first:
We will introduce “Components” in Bricks core
It’s now under “Planned” on the roadmap:
https://bricksbuilder.io/roadmap/#3026
It’s not a feature we will rush because another builder already has it.
In this planning stage, my best guess (not any guarantee or promise) is that we might have a testable beta for components at the end of Q4 this year.
With more than 50 replies, this discussion shows how difficult it is just to define this feature, its requirements, functionality, and possible implementations. All while nicely fitting into the existing Bricks approach & workflow. Well, not just to fit in, but to elevate it.
It also allows us to potentially consolidate the “global elements” feature, which doesn’t allow the saving of nested elements as global elements.
We also have to check if it makes sense to extend our templates to allow for “dynamic templates” (read: components) or if we should implement it as a stand-alone solution.
My current point of view:
Feature name: Components
This distinguishes it clearly from individual elements. But also from global elements, which are reusable but not customizable individually, as editing a global element updates all instances throughout your site. And from templates, a global collection of elements that can only be reused on a page as is in place. Although dynamic data allows for some degree of having an instance, but not really in the way a component would.
Components, on the other hand, allow you to have a master source for your reusable content and its styles (like a template) and the flexibility to overwrite certain (or all?) properties within the component in place while keeping its global/master structure, and unchanged content & styles intact.
Adding a “Components” tab in the elements panel seems like a good place to quickly access all components while at the same time clearly distinguishing them from normal elements.
Editing of the master component itself might be best done in a separate builder tab (like editing a template). Essentially removing the possibility of editing the master component by accident (which would affect your entire site).
Inserting and editing a component (let’s call it “instance”) should be possible inside the builder, right where you insert the component.
Does that make sense?
Did I miss anything?
Happy to hear your feedback
31 Likes
@thomas, thanks for the detailed insight into the Components feature for Bricks. Your dedication to differentiating “Components” from other elements clarifies a lot for the user base.
The “Components” tab in the elements panel seems like a logical and effective way to both organize and provide easy access to these new entities. It emphasizes their importance and keeps them distinct from standard elements.
Regarding the idea of editing the master component in a separate builder tab, I can see how this might be technically easier and more streamlined from a development perspective. It reduces the risk of unintentional changes and keeps the master editing environment consistent. However, the challenge of editing a smaller component on a near-empty page might pose a disconnect in terms of design context. In-place editing, while potentially more challenging technically, could offer a more contextual and intuitive experience for designers. To balance both approaches, perhaps a clear and distinct warning 
when editing the master component, a unique color in the structure tree, or a noticeable fade-out of peripheral elements could be implemented.
All in all, the direction Bricks is taking with this feature sounds promising. Your team’s effort and transparency are commendable!
14 Likes
Thanks for listening to the community and taking on the feature request. I am excited to see how this all eventually comes together.
I do agree with MaxZieb that having editing in place is a better user experience for the reasons he listed. This could even be extended for other things like templates as well (like header, footer, single page, etc…)
It’s actually even less useful in templates as I pointed out in a bug report a while ago as templates like archives, search, 404 don’t work correctly when using the template element to retrieve another template which itself can retrieve dynamic data since the query data for the template gets overridden by the main page. This actually works fine in the Bricks Editor but breaks on the frontend.
The bug below I wrote about this issue is marked no-bug but the only reason it is, is because I was told this is not how Bricks works.
Anyways, I am getting a bit sidetracked here…
I do also wonder if it would be possible to have Components within Components. I realize this opens a whole pile of technical issues that hopefully can be overcome if planned for from the beginning. I see a lot of use cases for something like this.
3 Likes
Nested components are definitely needed.
3 Likes