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
Whatever you do, please don’t make us edit components in a separate “magic area.”
When it comes to true efficiency and context and workflow, “Say ‘No!’ to ‘magic areas’” is a REALLY good standard to uphold.
18 Likes
This is so, so great to hear. Building with bricks is so smooth, up until the point where I need to edit 10 different pages to implement an update.
I think Components is a great name.
I think a new tab in the ‘Elements’ area makes perfect sense.
I don’t feel as strongly as some others do about being able to edit in place… a separate area would be OK with me, especially if it gets the feature released sooner. If we were able to edit in place, maybe a button/interface element to switch from ‘local editing’ to ‘global editing’ could alleviate any accidental edits. Though, some future update where components, headers, and footers could all be edited in place would certainly be a welcome update
Being able to insert them via the builder, similar to current elements, is certainly a high priority. I would also say that being able to create them from the builder (via right click on a parent element, similar to templates) would be fantastic. Though, I could copy/paste the elements into a new tab if needed (again, if that gets the feature out the door quicker and can be iterated upon).
I do think nested components are greatly needed. This could be a much better workflow than the current ‘global elements settings’ which are not comprehensive and a little clunky… we could just define the buttons we want to use, make them a global component, and stick them into any other sections/components.
Something that will be tricky is how components ‘inherit’ elements from their parents… If I have a component with an image and text box, and I have 10 instances of this component on the site, what happens if I add an image to the global/main/master component? What if some of my instances already have images added? The logic here could get tricky.
Another thing that I’d be curious to see would be some kind of ‘options’ interface… so we could make, say, an icon grid component and have options available for column count, icon size, etc. This could be handled with default Bricks controls per component, but a customizable set of options would be handy.
@thomas Thanks for considering this feature, and being responsive to your user base. I do think this will take Bricks to the next level for building large and scalable websites.
3 Likes
Nice 
Besides the magic area I agree.
Why are separate areas bad?
What I most hate on magic areas - and that will be even worse for components - is that they always give you a full width canvas.
Given you want to design a card component for a 3-column layout: If you build that card in a separate area, then you’ll build your card on 3-4 times the expected width and never see the real whitespace and proportions until you add it to your page. Then you see the result and go back and forth (for years) to get to the expected result.
I‘ve experienced that struggle long enough and thus, do not recommend it at all. To circumvent such a disadvantage I‘d probably copy the elements of the master component to it‘s expected place. Edit it in it‘s natural habitat and at the end copy it back to the master component.
What could you do instead?
Handle components in the builder as they wouldn‘t exist. Whenever you change a component it doesn‘t reflect it‘s changes to all others, it just becomes an edited instance of the component. An button „take over changes for master component “ becomes visible and would update the master component and all instances of it.
Benefits
- Edit and adapt components in their natural habitat, with the final dimension
- No interruption of the workflow
- No overwritten components by accident
Further suggestion
- Mark elements as components in the structure panel via slightly different background color (as loop items already get an additional icon)
6 Likes
Never heard the term ‘magic area’ before, you just mean a different area for editing?
3 Likes
Yes, the term has been used here so I sticked to it.
First of all, we need to understand where such a tool will be needed in practice. Here we need an approach from the particular to the general. We need a specific task that needs to be solved using existing elements of the constructor. In most cases, to create complex layouts, I close all tasks without any serious problems.
A template element is suitable for summarizing and automating content. But, even where it needs to be applied, in some cases I refuse the template and repeat the structure of elements without a template.
The problem of complex elements lies in additional requests and complication of the algorithm. This is not a good practice. For informational static sites, this is not critical and almost not noticeable. But for dynamic sites (online stores), each complication can greatly slow down the work of the site. Is he worth it?
There is no need to complicate anything without serious reasons.
I don’t think this will be too much of an issue. If you add a new element to the master component, then yes, all instances of this component should then display the new element. The only exception is if you add a condition to it - then it would only show in some cases.
Another consideration is to set default values for each property when building the component, in the case where no value is set when creating an instance. This will be essential to reduce rendering with errors.
Allowing for nested components is essential to an ideal workflow here. You could consider doing something like in Figma, where you have the choice to limit which components can be embedded as an instance, though that is not essential. However, if the master component of the nested component gets deleted, there will need to be a way to handle this.
My previous post in this thread shows some further considerations as well. I’d love the ability to use the variables within code blocks (for PHP or CSS). That way, if I ever need to write my own PHP to dynamically render HTML for something Bricks doesn’t support, then I can define variables at the component-level to be passed down to the code block.
2 Likes
Given the importance and scope of this discussion, add this to your “Survey Response” - whatever you and the Bricks team needs to do to justify this - this needs to be move from “Planned” status to “Working On Now”. Seriously.
My opinion is, this is more important and fundamental to how Bricks works than anything else in the roadmap. This isn’t for me at least, a “feature” but is a “Foundation” issue.
Seriously, even Oxygen did this better. Trying to go from Oxygen to using Bricks - this concept and approach to workflow stumped me for the longest time.
I am not knocking or making a dig with my comment. I am just stressing from my point of view, how crucial this is for me and many others as a user of Bricks. I would place this above ANY other feature request I have previously voted on.
PLEASE make this a priority?
Thank you
7 Likes
The “feature request” promises far-reaching capabilities beyond just functional encapsulation. It paves the way for delivering components via the remote template interface, creating a potential new market for these components. This should undeniably be a cornerstone of its rollout. Furthermore, it unlocks a vast array of utility frameworks and design collections tailored for renowned component-oriented tools like React and Vue. For instance, a majority of Tailwind designs and components could, in principle, be instantly accessible or seamlessly modifiable. This would effectively counter any objections against integrating such frameworks within a page builder environment. Just ponder the immense array of fresh possibilities this introduces.
Seeing the buzz around this, I can totally picture a whirlwind of growth, positioning the current Winden effort as just one of many framework integrations from that sphere in our community. I’m betting we’ll see a bunch of updates and projects jumping on the bandwagon. After all, it’s about blending in with what’s already out there. The future looks bright, and I’m stoked to see innovative projects integrated with Bricks Builder.
6 Likes
You need to chill. Thomas said there will probably be a beta available at the end of the year, which is totally acceptable.
There’s nothing wrong with allowing the community to express their level of importance and detail their particulars on this request.
When we respectfully provide our input and help the Bricks team “hear” our interest, this is what the community is for. Telling someone to “chill” when the input has been respectfully offered and not as some complaint is inappropriate.
Having input, details and sense of community interest is positive and helpful feedback as the product is developed is helpful as long it’s not just “baggering” which this thread is not. When the conversation is cordial, this is what the community feedback is for.
9 Likes
