Proof of concept / strategy decision: If / When to use properties vs attributes vs slots for complex data.

[damontgomery]

Are there best practices / guidelines for using attributes / properties / slots for complex data?

Related in some ways to #57.

Should we use properties, attributes, or slots <slot name="mySlot"></slot> in the web components for complex data?

Notes

Properties can take complex data such as objects. It can be easier to pass this data in to child components (other web components) or from JS frameworks.

https://lit.dev/docs/templates/expressions/#property-expressions

You can use this syntax to pass complex data down the tree to subcomponents. For example, if you have a my-list component with a listItems property, you could pass it an array of objects...

Attributes can only take simple data. More consumers (such as plain HTML / a CMS) can easily(?) construct these components. They are the default(?) way that Lit handles data / configuration.

https://lit.dev/docs/components/properties/#attributes

While properties are great for receiving JavaScript data as input, attributes are the standard way HTML allows configuring elements from markup, without needing to use JavaScript to set properties. Providing both a property and attribute interface for their reactive properties is a key way Lit components can be useful in a wide variety of environments, including those rendered without a client-side templating engine, such as static HTML pages served from CMSs.

Complex data

Complex data such as a list of paired child elements (header / content), can be constructed as a serialized string assigned to an attribute, a data object assigned to a property, or a set of nested <slot> child elements.

Supporting multiple paths

By default, Lit will convert attributes to properties. This allows the consumer to use either.

Providing both a property and attribute interface for their reactive properties is a key way Lit components can be useful in a wide variety of environments, including those rendered without a client-side templating engine, such as static HTML pages served from CMSs.

It may make sense to use converters to support complex data as both properties or slots, https://lit.dev/docs/components/properties/#conversion-converter

[damontgomery]

We use slots for content, properties / attributes for configuration when we can. See #57 (comment) for discussion of that approach.

Seems to work OK.