I think it's great. It's basically like Gutenberg Blocks but inside Bricks, or the opposite of GutenBricks. I can see letting a client / site owner into Bricks, restricted to only using Component Instances, so they can select from various Components I built, add multiple instances to a page, then edit only the instances via properties.
An interesting feature has been announced. Currently, the developer experience (DX) needs significant improvement; this constant switching between panels is painful for the wrists, making shortcuts essential. Additionally, many developers use wide or multiple monitors, so having more panels open simultaneously is not a problem. Thanks for a video
The current user experience feels a bit confusing and often requires too much back-and-forth navigation. I like the idea of keeping the Structure panel fixed to the content you’re currently editing. It would also be nice if the main component at the top were placed below in some sort of dropdown menu. The functionality is as expected, and I’m sure more property connections will be introduced over time.
Up in the design where the category pill is it would be great if that could be linked to a dropdown for categories, with predetermined category listings. I'm sure someone will come up with a clever solution for this.
Not really. There are still plenty of reasons to use a normal template over a component, but they do offer additional flexibility that will be incredibly useful. I still need to dig deeper to find more use cases, but my first tests make me want to hold off launching one of my site redesigns as I can see how components would make it better.
quite disappointing. The components were supposed to be useful for creating different styles on a common basis, but here we focused on the contents...but couldn't I already do it with ACF? just assign a template to a section...And then I find it too laborious...why not "simply" connect all the properties by default? why do I have to map them? you could make a system invisible to the user...
Connect which properties to which elements by default? How could Bricks know which elements a designer will want connecting and which they wont? If every text element was given a property there would be the question "how can i turn a property off if i don't want it?". Maybe having only the properties you want has page speed benefits etc. RE: common styles - it seemed to me that you can do that.
Then you have to create many section templates for different ACF fields or different query loops. Imagine your website has multiple post types and you need to create a card for different query loops and they have a similar design. ( A card with image, title and basic text for custom fields) You can create a standard card as a component. For query loop A (post type A), you can reuse the component and connect the {post_title} for the title, {acf_image_a} for the image, {acf_text_2} for the basic text. Then in query loop B (post type B), you can reuse the component and connect the {post_title} for the title, {acf_image_b} for the image, {acf_text_3} for the basic text. (Provided they have a similar structure) In the future, if the Component can accept condition as property then it will be more powerful so we can choose which element to render for each instance.
@@toby-green therefore, as I had imagined it, I would have placed in the parent component, next to each property, a small icon which, when clicked, indicated that that field could be modified by the instance. Communication could occur by automatically creating an id between the instantiated property and the parent. The process would definitely have been faster. Now obviously I don't know the bricks engine, I imagine that this continuous communication could have slowed everything down in some way...probable.
@@Happor You see, this is exactly the point, you are talking about design but the components developed in this way do not take design into consideration at all. It is identical for all instances.
This is encouraging, a bit confusing but promising. Cwicly did this first and well ua-cam.com/video/YZrSP8uXlAE/v-deo.html. I think Thomas and the Bricks team should get inspiration for some of their features from Figma and popular UX design software which pioneered the concept of components.
I think it's great. It's basically like Gutenberg Blocks but inside Bricks, or the opposite of GutenBricks. I can see letting a client / site owner into Bricks, restricted to only using Component Instances, so they can select from various Components I built, add multiple instances to a page, then edit only the instances via properties.
this is something I miss moving from Oxygen. Glad its finally here!
What? Oxygen has components?
@@ivan_vrabec Oxygen has it as Reusable Template
Thomas released it yesterday and I was waiting for your upload. Matt should sign you for official WordPress brand ambassador.
An interesting feature has been announced. Currently, the developer experience (DX) needs significant improvement; this constant switching between panels is painful for the wrists, making shortcuts essential. Additionally, many developers use wide or multiple monitors, so having more panels open simultaneously is not a problem. Thanks for a video
The current user experience feels a bit confusing and often requires too much back-and-forth navigation. I like the idea of keeping the Structure panel fixed to the content you’re currently editing. It would also be nice if the main component at the top were placed below in some sort of dropdown menu. The functionality is as expected, and I’m sure more property connections will be introduced over time.
Up in the design where the category pill is it would be great if that could be linked to a dropdown for categories, with predetermined category listings. I'm sure someone will come up with a clever solution for this.
This is really great! Do you think this will replace templates?
Not really. There are still plenty of reasons to use a normal template over a component, but they do offer additional flexibility that will be incredibly useful.
I still need to dig deeper to find more use cases, but my first tests make me want to hold off launching one of my site redesigns as I can see how components would make it better.
Confusing
Glad it wasn't just me
Bricks is killing Elementor ..
For a long time. ;)
quite disappointing. The components were supposed to be useful for creating different styles on a common basis, but here we focused on the contents...but couldn't I already do it with ACF? just assign a template to a section...And then I find it too laborious...why not "simply" connect all the properties by default? why do I have to map them? you could make a system invisible to the user...
Connect which properties to which elements by default? How could Bricks know which elements a designer will want connecting and which they wont? If every text element was given a property there would be the question "how can i turn a property off if i don't want it?". Maybe having only the properties you want has page speed benefits etc. RE: common styles - it seemed to me that you can do that.
Then you have to create many section templates for different ACF fields or different query loops.
Imagine your website has multiple post types and you need to create a card for different query loops and they have a similar design.
( A card with image, title and basic text for custom fields)
You can create a standard card as a component.
For query loop A (post type A), you can reuse the component and connect the {post_title} for the title, {acf_image_a} for the image, {acf_text_2} for the basic text.
Then in query loop B (post type B), you can reuse the component and connect the {post_title} for the title, {acf_image_b} for the image, {acf_text_3} for the basic text.
(Provided they have a similar structure)
In the future, if the Component can accept condition as property then it will be more powerful so we can choose which element to render for each instance.
@@toby-green therefore, as I had imagined it, I would have placed in the parent component, next to each property, a small icon which, when clicked, indicated that that field could be modified by the instance. Communication could occur by automatically creating an id between the instantiated property and the parent. The process would definitely have been faster. Now obviously I don't know the bricks engine, I imagine that this continuous communication could have slowed everything down in some way...probable.
@@Happor You see, this is exactly the point, you are talking about design but the components developed in this way do not take design into consideration at all. It is identical for all instances.
I'm a bit disappointed. It's way too basic and limited, advanced features are missing. I don't get why it took so long.
Its a beta :-)
@@rebelinc Beta is not far from production
2nd one
First one here😊
This is encouraging, a bit confusing but promising. Cwicly did this first and well ua-cam.com/video/YZrSP8uXlAE/v-deo.html. I think Thomas and the Bricks team should get inspiration for some of their features from Figma and popular UX design software which pioneered the concept of components.