IMPLEMENTED: Global Components

Feature Requests / Improvements
1

I don’t see a lot of mentions of Global Components in the forum Feature Requests but this really is a must have feature that would really push Bricks to be a star among Page Builders.

It really should be made a priority.

So what do I mean by a global component?

The Bricks idea board has a good explanation of it:

It basically is a way to manage recurring layouts while still allowing you to override content (like text, images, video, etc. whether it is dynamic or static) or even styling.

Webflow offers components that can do this. See:

They even have a video showing it off:

To make Global Components even better than Webflows version is allowing the ability to lock certain parts of components from being edited. For example a user that is not an admin using an instance of the component in an article could only modify certain content or styling of that instance.

I see the locking feature being using a lot for blog posts. A user who can create posts for a blog would only have access to certain components and only be able to edit the content parts of the component (the other attributes would be locked or maybe even not visible). This would be less confusing for article writers when creating blog posts in Bricks as they would just drag the components in they need and add the text and image content. It would lead to a much more consistent design between articles (especially if you have more than one writer).

Having Global Components would make maintaining the website much easier in Bricks (and make it much easier to scale as well). If the design of the component or even the website is ever updated we just have to update one source of truth and not every single page the “component” is on.

58 Likes
2

With both hands and feet I support the idea of adding such functionality to Bricks! :sunglasses:

I think this kind of operating logic is best added to the template element in Bricks. In essence, templates are the same as components. There’s no need to reinvent the wheel here.

There are also global elements in Bricks. Perhaps dynamic options for them wouldn’t hurt either.

10 Likes
3

Yup agree, whatever makes sense from a development point of view.

Not sure what they would want to do since there is already something called a Global Element (which is pretty limited in functionality).

4

@thomas please consider implementing this. It would instantly take Bricks into a league of its own.

5 Likes
5

I’m so here for this.

6

Maybe sharing on Facebook could help boost this :thinking:

7

100% yes, this feature is really needed. I’ve added my support to various feature requests in this direction (some call it global components, others refer to ‘more granular editing control’ or other names, but the idea is the same: we need some way to build complex layouts where the content can change but the styles and layout are global.

I can do my best to pre-configure a layout, but almost always I need to go back and update something as I develop a site: spacing, mobile sizing, etc. Using the current templates, I have to re-apply these changes anywhere I have placed a template (or use a global instance, where the content cannot be updated).

A system where layout & styles can be set globally (or even better, where we can choose which settings are global) would be the perfect solution to this, and would mirror best practices for code-based DRY development. ++100%

1 Like
8

Another Idea I had for this would also be the ability to have a Global Component within another Global Component.

For example you could have a Global Component for a Card that could then be used in other Global Components that you have setup for different sections.

5 Likes
9

I am reviving this thread! Here is why:

Shortcodes, in essence, serve as non-visual components, offering properties through attributes. Interestingly, all elements/blocks can be perceived as components that expose properties via an (inspector) interface. However, this requires a certain level of coding proficiency to accomplish.

Several visual alternatives to this process exist, ranging from shortcode builders and block builders to recent developments such as meta builders like Pinegrow. The feature request for an element builder (essentially a type of component) can be found on our forum here.

Cwicly is now upping the ante by rolling out a robust version of this feature. Users can select elements on the canvas and semantically group them into a reusable component, without the need for adding an extra wrapper. Furthermore, it’s possible to add properties to expose and link them to fields within the component. Editing a component even permits the user to drag from the current working canvas directly into the component.

This model promotes global usage and modification. It also allows nesting to any depth, with child elements revealing their properties to the next level up. Hence, these properties can be interlinked. For instance, a ‘Label’ field property can be populated by the ‘Call-to-Action’ field property of a Hero section component it’s added to. This, in my opinion, is incredibly powerful and versatile!

11 Likes
10

To be clear, Bricks already has “global components.” What it doesn’t have is Dynamic Components – components that can be edited dynamically without losing global control of their structure and behavior (like the Webflow video shows).

This is what we need. And when/if that’s added, there’s an excellent opportunity for Bricks to improve the whole components workflow as well.

Two other suggestions:

  1. Users should be able to edit any component directly in the canvas workflow without first navigating to a templates/components area.

  2. Components should live separately from templates in terms of the organization in the panel/library/wherever as they are two different things.

39 Likes
11

In Vue land, this is like props for components - we need to have them!

3 Likes
12

While it is possible to use the existing template system to accomplish something similar to what Webflow had for their components it’s not an easy workflow.

You’d need to create custom fields for each content element of a component and include a default text within bricks to conditionally hide if the custom field has a value and then set a condition to display the custom field value.

Maybe it could do everything but it would be close but it would be a lot of work to set up and management wouldn’t be the easiest thing.

I think I’ll create a video about this just in case it’ll be helpful for anyone to see the limitations and difficulty in setting up and managing.

4 Likes
13

This approach doesn’t work with certain template types like archive pages (which is a pain as I ended up having to copying and pasting the section). I had done this approach for a hero section where the title lede and image was retrieved by dynamic data. It works in the Bricks Editor but not the front end as the data queried for the archive itself overwrites the data for the actual template.

I made a feature request to improve on this here:

If you look at the feature request, you will find my initial bug report about the problem as well and the Bricks team response.

1 Like
14

I agree. Global Components are needed in Bricks! A priority!

1 Like
15

Cwicly was on my radar when they were still in beta and allowing a few to dl and try-out. It was and STILL is a very hard choice for me because of having to use gutenberg. “For me”, I personally dismantle gutenberg right from the install of WP.

BUT, Cwicly introducing this ‘component’ building feature is major! Could totally do away with these pre-built builder ‘elements’ that are so limited in being able to control or customize the functionality and styling.

I’m presently looking at https://ui.shadcn.com/ for dashboards and components. But having major issues with js conflicts and I refuse to use tailwind WITH wordpress. As of right now using node.js plugin I’ve found a way to remove tailwind dependencies and use vanilla js but after packaging locally and then trying to use on centos server = major issues… so I’m still working on it.

If Cwicly beats Bricks to the punch on this I would have to jump ship… simply because if these pre-built elements and implementing lotties are more important than one being able to build components and truly dynamic templates / partials RIGHT IN THE BUILDER canvas, it tells me all I need to know about the future of this builder.

3 Likes
16

“Global” is already there…

17

This is exactly what I was meaning when I recently published this post in FB : Bricks Community | Facebook and sending people to upvote the feature request.

I’m pretty sure the Bricks team knows about this, but a little communication (given the growing expectations from the community and the competition rapidly adapting) from them could be really appreciated : @timmse @thomas would this be very complex to implement ? I’m sure many, many people would love to get onboard of this ambitious addition and help you design it if you wanted.

3 Likes
18

Not that many judging by the low number of votes.

19

@BGdev If you’re interested in exploring web components further, a comprehensive overview can be found at this website.

Here is the difference between templates and components in my opinion:

Template:

A template is essentially a pre-designed webpage or a section of a webpage. It’s a blueprint that provides a consistent structure where content and images can be inserted. In addition, Bricks offers a way to make these templates “global”, so that they can be automatically inserted based on rules or by placing a Bricks template element on the canvas. Unlike components, templates do not accept properties on an individual instance basis.

Component:

A component, on the other hand, is a discrete, reusable piece of the user interface (UI) — think of elements like buttons or headers. Components encapsulate specific functionalities or design features and are fundamental in constructing complex user interfaces. Unlike templates, components do accept custom properties on an instance basis, allowing for flexibility and customization.

In the context of Bricks, the elements are already components by this definition. This thread is more about a visually-oriented approach to components. The goal is to group several Bricks elements together, save them similarly to a template, and attach properties to them that can be altered per instance while maintaining the internal structure’s single source of truth. Ideally, this should be done in-place, but an implementation similar to the current Bricks templates would also be an acceptable starting point. The primary difference compared to built-in Bricks elements is the visual, no-code approach, as Bricks elements themselves can be easily coded and adhere to the component paradigm.

The terms used for these concepts can vary across different platforms. For instance, in Gutenberg, what I have labeled “templates”, “global templates” and “components/Bricks elements” are referred to as “Patterns”, “synced Patterns” and “Blocks” respectively (see WordPress 6.3). However, Gutenberg (much like Bricks) still lacks the concept of “Synced Patterns with Properties”.

In Bricks builder, the terminology can be a bit confusing since everything is termed a “template”. Whether you are inserting a template, using a Bricks template element, or accessing global Templates in the backend, they all refer to different aspects within the same broad concept. This makes distinguishing between these terms a bit challenging, and makes it even harder when talking about a “component”. Despite the difference in nomenclature, the underlying principles of reusable design structures (templates) and (components) remain the same across different web design and development platforms.

I’m hopeful that Bricks will strike a balanced and intuitive approach towards visual web development when offering this feature.

6 Likes
20

Problem is the ‘number’ of votes isn’t indicative of “who” is upvoting. :thinking:

1 Like