Firstly @Louis, thank you for all of the work on Components, this looks truly excellent and will be revolutionary in developing reusable, configurable blocks that we can extend, customise and share between sites.
Here are some initial thoughts regarding the upcoming Cwicly components beta.
-
Conditional visibility based on content:
I know that keeping it simple is good and I am grateful that visibility properties are included. I am also glad to hear that the existing Cwicly visibility conditions will be supported. There seems to be one gap that I believe will be extremely beneficial to fill - the ability to show/hide dynamically based on content. Some classic examples of common use cases being a. if a paragraph is empty, that the entire p tag be removed from the output, b. if a button’s link has not been set, remove the button from the output. -
Style properties:
This is exactly what we need for non-technical clients. One enhancement to this can be to have different style property groups, not just one group. For example - I can imagine creating a “Theme” property and allowing them to choose from “Dark”, “Light” and “Highlight”. At the same time I may want to add another style property called “Type” with the values “Simple”, “Advanced”, “Full”. With only a single style property group, that would require a lot of combinations (e.g. “Simple Dark”, “Simple Light”, “Simple Highlight”, “Advanced Light”, “Advanced Dark”, etc) even with just two variations and obviously any additional ones needed would exponentially increase this. My request is to make Style a property type (like Text, Colour, etc) and then it can be added in a similar way. -
Responsive properties:
@Louis, You demonstrated having responsive component properties, which has incredible potential. I just want to check whether this applies to background images/videos also, as I know there are upcoming feature requests to implement these. -
Editing restriction based on role:
This will be extremely important and it will be great to get confirmation of exactly what can be done with this in the short term and longer term. Ideally having fine-grained control is optimal and at the same time the most important feature would seem to be restricting edit access per role/user. For some clients, we may want to conditionally allow editors to reorder blocks and change their visibility per instance but not delete them for example. For other clients, we may want to completely lock down the components and only allow editing of properties.
I also observed what may be a bug:
- Nested components default properties:
@Louis, when you were demonstrating the component nesting and added buttons, you then connected the title property to those buttons. I noticed that only the second and third buttons were populated (where the title was explicitly set), the first button’s text content was not populated even though a default was specified for the title property. This may be desirable in some cases and having a setting to allow this may be worthwhile and I also believe the default behaviour should populate the default value to nested components that use it.