Settings System Manager meet Design System Studio. Design System Studio meet Settings System Manager

Love this idea. Would encourage consistent experiences of components throughout apps, and minimize the “declarative refactoring” burden for Skuid builders.

A big complication here for implementation would be the Model / Field dependence of different components, e.g. in your example, a Table with a “Mark Rows for Delete” action preconfigured, the action would need to have a Model, so Skuid would need to abstract out some of those strong bindings to particular Models/fields in order to make the Table configuration reusable across other tables connected to different Models / Fields. Not saying it’s impossible — we could handle it more like we do Action Sequence inputs, and make it generic.

Will say it again, I love this.