‘Component scope’ is a feature being added to many BricksExtras elements, which will allow for better use of elements if using within components or nested components. Let’s go through what it is, why may you need it and some examples..
Note – for a <2 mins TDLR showing a screen recording of setting up a modal + trigger inside of a component, before & after component scope to highlight why it can be needed – https://support.bricksextras.com/recordings/ze06oKhOYEs3aBqromSl
Using Selectors to Connect Elements
Many BricksExtras elements have the ability to ‘control’ other elements, it’s important for flexibility in how we can build things. Instead of triggers/toggles/controls being hardcoded into elements themselves, which would only add layout restrictions, we instead often use other elements to control.
This is generally done with selectors to connect the elements.
Some examples..
- The way we choose which slider is being controlled by a custom navigation arrow – we add in the selector for the slider to control.
- The way we choose which button opens a mobile slide menu – we add in the selector for the button or toggle.
- The way we choose which content is changed by a toggle switch – we add in the selector for any content switcher(s).
Using selectors is how we ‘tell’ the element which other element to connect to.
Using with Components
Generally speaking, when working with components in Bricks, we’re no longer just creating something to live in that specific place where it’s being added.. we’re creating something with the intention of reusing it elsewhere.
So one of the most important things to consider when working with components in Bricks is – we can’t assume where or how they’ll be used in the future when we’re creating them.
The idea to create something that is global, where we set it up in one place, configure the functionality / add our styles, and then be free to use it elsewhere (for different content purposes).
This means, most of the time, any functionality ideally needs to be ‘self contained’ within that specific instance – we don’t want add a component somewhere on a site and have to worry about it behaving differently when used somewhere else later on or alongside other components.
Anybody who has already been using components in Bricks, may have already spotted a ‘problem’ in regards to using selectors..
<div class="brxe-eaishj brxe-block my-component">
<h3 class="brxe-fqcmsu brxe-heading">Instance 1</h3>
</div>
<div class="brxe-eaishj brxe-block my-component">
<h3 class="brxe-fqcmsu brxe-heading">Instance 2</h3>
</div>
<div class="brxe-eaishj brxe-block my-component">
<h3 class="brxe-fqcmsu brxe-heading">Instance 3</h3>
</div>All the elements within each component instance are exactly the same element – same element ID (eaishj), same classes, etc. No unique identifiers unless manually added in via properties.
This isn’t a bug, it’s just how components are. It’s by design. But it does mean selectors alone are no longer useful for syncing elements. (we can’t know in advance if there’ll be other elements on the page sharing the same classes or Bricks’ element IDs)
This goes for all elements, including Bricks’ own native elements.
An Example
If we try adding two native Bricks elements, an offcanvas element and toggle element, place them both inside of a component and then re-use that component in the future on the same page, we hit an issue.. the toggle doesn’t know which offcanvas to open.. because both component instances contain the same elements.
In other words, which ‘my-toggle‘?, every instance of the component would contain the same classes.
How to target just the toggle within that instance? A workaround is to set up both a ‘custom class’ as a component property and a ‘CSS selector’ as a component property and then each time the component is used, we’d need to make sure to create a new class and a corresponding unique selector to match for every instance.
Although this will work around the issue, it’s not really a set and forget solution, it requires doing it every time for each new instance and so isn’t dynamic – it can’t be fully configured from the original global component settings.
There is no ‘dynamic’ way to tell the toggle inside of a component to only open that one specific offcanvas on the page, because every new instance will be an identical copy. This is the same for all elements that use selector settings.
So, rather than having to do this everytime.. Component scope is the solution.
Component Scope
Under every ‘selector’ setting now from BricksExtras v1.5.4, there will be a new component scope setting.
When enabled, it’s simply telling the element to only consider the current component instance for elements to connect to.
This is the ‘dynamic’ way to connect the elements without having to change classes and selectors for each individual instance.
Each element will connect only with elements within that instance, future proofing the behaviour wherever it is used.. essentially making the element ‘component-aware’.
This also applies to nested components, where it’ll only consider elements within the nested component that it finds itself inside of.
Query Loop Scope
If BricksExtras elements are inside of a query loop, it’s already assumed the only elements we’re wanting to connect to exists inside that individual loop item. There’s already a built-in ‘query loop scope’ type mechanism in place behind the scenes.
This has been the case for quite a while, it’s the reason why modals / offcanvas / lightboxes / copy to clipboard / toggles / popovers and others can already be used inside query loops without concern about the same classes being duplicated by the looping.
We just add in our selector and it just works.
This behaviour remains unchanged. So if the elements are going to be inside of a component, but are also already inside of a query loop within that component, then component scope won’t be needed as it’ll already be only considering the elements found within that loop item.
Component Scope Example Use Cases
Really, any time we’re connecting elements via selector where both elements are inside of a component it’ll generally be a good idea to enable the component scope option to future proof.
Grouping lightboxes – Let’s say we’re connecting a lightbox to a gallery (either in a slider, or maybe Bricks’ gallery element or any other). If that entire gallery + lightbox solution is going to be used inside of a component to be used in other places, then enabling component scope on the lightbox is a good idea. It will ensure that the lightbox is only going to be showing the images for that one gallery.
Likewise, if we’re wanting to group all the images together from the gallery to be included in one lightbox, enabling the component scope option for the grouping also makes sense.
Copy to clipboard – Let’s say we’ve created a little card component which displays some type of discount code and there’s a corresponding copy to clipboard element to copy the content. It’s set up to grab whatever content it finds inside of the card (the discount code) via a selector when clicked. Here we’d want to make sure the only content being copied is the discount code from that specific instance, so enabling component scope makes sense.
Example Where Wouldn’t be Needed
Of course, it’s not always useful to restrict functionality to within a component, which is why it was added as an optional setting rather than being a default.
An example is.. if we had a component that was just a Pro Slider, nothing else, to be used multiple times across a site with different content. If we came across a situation where we wanted to then use that component but sync it with another slider on a page, enabling the component scope wouldn’t make sense.
This is because only that slider exists inside of the component, not the other slider. So restricting to within the component won’t be helpful.
Enabling component scope only makes sense if both elements to connect exist inside of the same component.
Note that the component scope option itself can also be controlled via a property – so it’s also possible to enable the scope conditionally where needed, and not for every instance if there are some exceptions.
That’s it
Hopefully this post delivers a better understanding of why the feature was added, and situations where it may be useful. It’s a relatively simple feature to use, but knowing the ‘why’ behind should give more confidence when using components.
The main goal when thinking about components & BricksExtras functionality was to maintain the current workflow as much as possible. By adding in this new component scope, it allows us to continue using selectors in exactly the same way as before, but free of concern of where/how the components will be used in the future.