Enhancing Object Variable Types In Sveltia CMS: A Feature Request

by Lucas 66 views

Hey everyone,

I wanted to share some thoughts on how we could make the object variable types in Sveltia CMS even more powerful. These enhancements are likely for v2 or later, but I wanted to document these ideas while they're fresh in my mind. Object variable types are already fantastic for handling conditional fields, but I believe a couple of key improvements could significantly boost their utility.

1. Flexibility Beyond Objects: Allowing Any Widget Type

Currently, object variable types are restricted to objects, which makes sense for Variable Types Lists, primarily to facilitate the injection of typeKey. This is particularly useful in scenarios where distinguishing between different object types within a list is crucial. For instance, in a blog post editor, you might have various content blocks like paragraphs, images, and videos, each represented by a different object type. The typeKey helps identify which type of block is being dealt with, ensuring clarity and proper handling of the data.

However, I argue that developers should have the flexibility to manage potential ambiguities themselves. There might be cases where different data types are sufficient, and the typeKey isn't necessary. In such situations, limiting the choices to only objects might feel restrictive. For instance, you might want to use a simple text input or a number field directly within a variable type, without wrapping it in an object. This could simplify the data structure and make it more intuitive to work with.

Consider a scenario where you're building a form with conditional fields. Depending on the user's selection in one field, you might want to display additional fields. In some cases, these additional fields might be simple text inputs or checkboxes. Forcing these fields to be part of an object can add unnecessary complexity to the data structure. Allowing developers to use any widget type directly would provide a more streamlined and efficient way to handle such situations.

For Object Variable Types widgets, the object keys already serve as unique identifiers for the types, eliminating any ambiguity. Each key corresponds to a specific type, making it clear which widget is associated with which piece of data. Therefore, it would be incredibly beneficial to allow any widget type to be used, not just objects. Imagine having the freedom to use a color picker, a date selector, or even a custom widget directly within an object variable type. This would open up a world of possibilities for creating more dynamic and user-friendly interfaces. This enhancement would streamline workflows, reduce unnecessary complexity, and provide developers with the tools they need to build exceptional user experiences.

2. Unleashing Multi-Type Magic: allow_multiple or allow_multiple_types

Imagine the possibilities if we could add multiple types, or object keys, to our object variable types. Of course, we'd only allow one instance of each type since the type name acts as the object key, ensuring uniqueness. But, being able to create an object with multiple keys, each holding a different defined type, would be a game-changer.

Think about building a complex form where users can add various types of content blocks. Each block might have different properties and input fields. For instance, a text block might have fields for the text content and formatting options, while an image block might have fields for the image source, alt text, and caption. Allowing multiple types would enable users to mix and match these blocks seamlessly, creating rich and dynamic content layouts. This feature could significantly enhance the flexibility and versatility of Sveltia CMS, making it an even more powerful tool for content creators and developers alike.

Combining this with the first feature—allowing any widget type—would create a fantastic UX improvement, especially for optional fields. Let's take image attributes as an example:

...
{
 name: "imageAttributes",
 label: "Image Attributes",
 widget: "object",
 allow_multiple: true,
 types: [
 {
 name: "alt",
 label: "Alt Text",
 widget: "string",
 },
 {
 name: "title",
 label: "Title",
 widget: "string",
 },
 {
 name: "width",
 label: "Width",
 widget: "number",
 value_type: "int",
 },
 ...
 ],
},
...

In the UI, users could click Add Image Attributes and choose the specific attributes they want to fill in. No more cluttered interfaces with fields that aren't needed! This would streamline the editing process, making it more intuitive and efficient. Think about how much cleaner and more user-friendly your forms could be with this feature. Users would only see the fields they need, reducing cognitive overload and making the experience much smoother.

This kind of UX is a total game-changer when you have many optional fields. It transforms a potentially overwhelming form into a manageable and enjoyable experience. By selectively adding fields as needed, users can focus on the task at hand without getting bogged down by unnecessary clutter. This approach not only enhances the user experience but also improves data quality by ensuring that only relevant information is captured. The ability to dynamically add fields based on specific requirements opens up a whole new level of flexibility and customization in form design. Imagine the possibilities for creating complex forms that adapt to the user's needs, providing a tailored experience that maximizes efficiency and satisfaction.

2 Bonus: Mixing fields and types for Ultimate Flexibility

Building on the image attribute example, imagine if we could use fields and types together. This would allow us to define a set of always-visible fields alongside the option to add additional, hidden fields as needed.

Here's how it could look:

...
{
 name: "image",
 label: "Image",
 widget: "object",
 fields: [
 {
 name: "src",
 label: "Image",
 widget: "image",
 },
 ],
 allow_multiple_types: true,
 types: [
 ...
 ],
},
...

We could have some 'always visible' fields, like the image source (src), and then the option to add 'hidden fields' like alt text, title, or width when necessary. This prevents the UI from being cluttered when those extra fields aren't needed. This feature would be incredibly valuable for creating complex content structures where certain fields are always required, while others are optional and context-dependent.

From a development perspective, this translates very efficiently into actual Objects, HTML elements, components, etc., without needing to transform the data. The data structure naturally reflects the desired output, simplifying the development process and reducing the need for complex data transformations. This is particularly beneficial when working with frameworks and libraries that expect data in specific formats, such as React components or HTML templates. By aligning the data structure with the expected input, developers can streamline the integration process and avoid common pitfalls associated with data manipulation and conversion.

Imagine the possibilities for creating reusable components that can adapt to different content types and layouts. With the ability to mix fields and types, developers can build components that are both flexible and efficient, reducing code duplication and improving maintainability. This approach promotes a more modular and scalable architecture, making it easier to manage and extend complex applications. By leveraging the power of object variable types and the ability to combine fields and types, developers can unlock new levels of creativity and efficiency in their content management systems.

I'm excited to see how these features could enhance Sveltia CMS and create even better user experiences. Let's discuss these ideas and make Sveltia CMS the best it can be!