I just watched this video again:
I want to offer an idea for how the custom properties are created/selected to be dynamic.
What is in the video is acceptable but I feel it’s too many steps and not very intuitive. Having to create the properties as if they were custom fields and then connecting the properties to the elements like dynamic data, it’s not very smooth.
I want to offer an alternative workflow.
First you would turn the element into a component as seen in the video, then you go into component edit mode.
In edit mode, you have the whole style browser as usual. From here, why couldn’t we directly select which styles and content boxes should be dynamic?
Imagine you are in component edit mode and you adjust the background color. This is just normal styling, but it would be global for all components. Now imagine there is a special button like “convert to dynamic” and you simply click that and it’s DONE. The color you select “normally” becomes the default, but since you tagged the field as dynamic, it now automatically becomes a style that can be changed on any instance.
There would be no need to go through creating custom fields and linking dynamic data. It would all be done automatically simply by marking that particular style or content box as dynamic for the component.
Now when the component is added or copied somewhere, the styles/content you see are just the ones marked as dynamic while in edit mode. And if you enter component edit mode again, you will again see all the normal properties (defaults) along with those previously selected as dynamic. You could quickly mark another property as being dynamic and then save and move on.
It’s far less steps than creating custom fields and linking them.
Or maybe editing components and marking the dynamic fields could be a combination of both methods?
There could be cases where the dynamic data itself comes from dynamic data!
For example, what if you want the background color to be dynamic for the component, and yet it’s also dynamic in that it is chosen statically for a certain page group? In other words, all such components that are under a certain parent page should have a purple background. In this case the background color is dynamic for the component, but it’s actually static because it’s the same for all pages under this parent page. If that makes sense.
This is where doing custom properties could be helpful, as the property itself could include dynamic elements like code or custom CSS or conditional logic.
You could even have a system where multiple custom fields can be creating for the same style, and then have conditional logic applied to which style becomes the one that is editable or statically set. E.g. “only when on the home page does this style become editable, otherwise is stays as the default.”
Or in the example before: “if component is on a child page of X, this color is not dynamic and is instead purple. Otherwise it’s dynamic.”
This leads to the concept of having a kind of global style or “theme” ability that applies to components. An idea where, during Christmas, certain properties that are defaults or statically assigned can have different styles under that theme. This seems complex, but kinda makes sense. Like if you want to edit all your defaults and static conditional defaults temporarily or make them “themed” across a group of related components. You can still maintain defaults, and fully dynamic instance fields, plus dynamic properties that can be conditional, all of it, under one “theme”.
Some of that could perhaps be solved with simple classes. Like if you set “christmas-theme” on the body tag. But how does that really filter down into component defaults and custom fields and dynamic data? Can individual custom properties have their own class-based alternatives? How could those properties be overridden in the presence of the christmas-theme class?
Just something to think about!