in main post feedback for components we talked about so many different ideas I think it is about time we have seperate topic about Nestable Components because it is very important that it deserves having its own topic.
. Why We Need Nestable Components ?
Long story short:
1 - We need nestable components for complete Component based workflows.
2 - Nestable components will make bricks builder more scalable and agency/enterprise ready.
. Explanation and Examples
Right now we have dynamic components but those components can only be used as they are we cant nest other components under each other or under layout components.
Idea is to have (atleast for the layout elements) nesting the components under other components. This way we can create our layout components, section components, loop ready, condition readyā¦etc components and then emergently/procedurally use all of them with nesting.
This gives us chance to hide the native elements and force interns, teams, departments and client teams to use components only and protect the CI. This way we can create Complete Component based workflow and protect the websites design rules and corporate identity rules easily.
I completely agree, but to avoid confusion, I think this should be named āSlotableā instead of āNestableā. Currently, itās possible to place components inside components, which is being called āNested Componentsā by the changelog / docs of 2.0.
My view on this feature: add a Slot element inside a component, and display all nested / slotted elements at the location of the slot. This might also open up possibilities for multiple slots per component, but Iām not sure how this could be implemented UI/UX-wise. Maybe add a ānameā or āIDā field to the properties of the slot element, and then display these slots as fixed elements underneath the component element? Example:
This also allows for Query Loop components / re-usable Query Loop in the form of components.
Btw, my proposed solution is heavily inspired on the way Vue handles slots: Slots | Vue.js, it just needs a visual implementation to fit inside the builder.
Especially with clients, this is a key feature. Just look at this Webflow exampleāsee how they allow nesting. Currently, the ānestable componentsā are not truly nestable. I donāt understand the integration. Just let us nest them like Cwicly or Webflow.
Iām not sure if I understand this - can you elaborate a bit more on this, how would that help with the reusable query loop? You can already connect query loop to the component.
Iām referring to something thatās similar to - or at least a workaround for - the idea over here: Idea board ā Bricks
Currently, the components indeed do support connecting a query loop. However, what Iām looking for is a way to save a Query Loop itself, instead of having a Component to which a Query Loop has to be connected.
For example, when building a WooCommerce site, Iāve got multiple places where I want to add a rather advanced Query Loop which loads a specific set of products. Currently, Iād have to either manually copy the Query Loopās settings, or programmatically add a custom Query Loop which has the same settings.
With Component slots, Iād be able to create a simple Div component, put my Query Loop on it, and add a Slot inside the div. I can then use that component anywhere Iād want to like a regular div, but the Query Loop would automatically be set. This would also save a lot of time and effort when having to change the Query Loop, as youād only have to change the Component.
Of course, a dedicated Global Query Loop manager (which is what they meant in the Idea I linked to above) or something like that would be the ultimate feature to handle this, but this can also be one of the possibilities with Component Slots
@Panag thatās what I meant in my first reply above: for regular elements, āNestedā means that sub elements can be added to the main element, whereas āNested Componentsā in 2.0 means that Components can be added inside other Components (but only when editing them). I get that in terms of linguistics itās both correct, but I also understand that itās quite confusing at the moment.
Thanks for the detailed feedback. Weāve added this to our to-do list.
I renamed the thread to āComponent Slotsā instead of āNestable Componentsā because the original title is vague and may be less accurate. In Bricks 2.0, nesting components is already possible. You can insert a component inside another component.
What youāre actually describing is the ability to inject elements or components into a component instance, not just nest them within the main component. That requires a proper slot system to define exactly where those injected elements should render inside the component. Without slots, thereās no way to control placement within the component layout, which makes it useless for anything more advanced than a single layout element structure.
Query loops have other problems as well, which would all be fixed by a Query loop element, which - to fit to the thread language - would have a slot to place the component, element or even multiple elements that are looped. The special query loop item could even be copied and contain a dropdown to select from already set up queries.
That would solve all known query loop shortcomings at once.
Loop any element and even multiple root elements, as you wish (quite helpful for the unsolved problem of building an event listing with month dividers).
Easily add or remove query loop to elements
Manage all queries from one component e.g. via dropdown. No special area needed, no new UI - nothing.
Iām confused. You want to convert the layout elements into a component so that you can use other components in it? Why donāt you use the default layouts? Has this approach been implemented in another builder before? Or is this the first time thereās an idea for it?
Mixing components with default elements will mismatch the component/classes workflow with id workflows. It will only create a mess and it is not long term maintainable setup. So your recommendation will make the full component based workflow impossible. Read everything I wrote and watch videos you should understand it.
There are more details about not just backend but frontend dom side of it aswell I am sure dev team already knows what I am talking about. So wait and you will understand clearly when the feature is ready.
I plan to make videos too. People dont know what they dont yetā¦
We dont like block editor ux is bad tons of dev friendly features are missing and I agree BUT block editor backend is quite powerfull. It is just shame the lead developers dont have clear vision and they move/think very slow.
% agree
