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
Global Components have just been marked as In Progress with the first beta expected as early as late September or early October.
6 Likes
Amazing 
… WIP! @thomas, I truly appreciate the effort and dedication you’ve shown in pushing the limits. Thanks for your time.
4 Likes
@thomas I can envision a global component as a nestable element, turned into a global element, with the ability to define and modify properties through individual instances. With a similar approach, I believe that the basic structure might already be in place; however, it would need to be expanded and adapted. what do you think about this approach ?
This might also be a great time to think about how container queries might be implemented in the future. It feels like components would be a good candidate for how that functionality might be encapsulated.
1 Like
I interpret end of Q4 as December, not September.
3 Likes
That is great. Yeah, not on Facebook. Thanks for cross posting.
1 Like
Bricks Team, when working on Global Components can you make sure they can be imported and exported maybe even separately from templates?
Not sure how you are planning for it to work but when importing templates that use pre defined components (that already exist on the website) I would like the option of using the existing component that is on the website (obviously it has to be the same version of the component) or creating a new component (even if it is virtually the same thing). I am assuming the component is maybe saved with the template just in case it doesn’t exist on the website the template is being imported into.
1 Like