Should properties be exposed as attributes by default? #2497
Replies: 3 comments
-
tldr: I use quite a few properties (as in class fields) in my components, but few of them are Lit's reactive properties (like Though, that's because I separate my domain (business logic) from the UI state and use reactive properties for UI state only, while using my own proxy based state management for the domain objects (compago). For example, if I'm building a blog, I have an object (aka entity) called Article and it can be complex with nested objects, arrays, etc. On the client side, the object is wrapped into a proxy ( |
Beta Was this translation helpful? Give feedback.
-
For UI components (button, accordion, tabs, card...) I think most properties tend to be reflected to attributes cause they're usually primitives, so it's convenient. When I'm using Lit for an entire application though, I agree, I use mainly properties and I don't care at all about attributes, cause I usually pass objects, arrays, functions, etc... |
Beta Was this translation helpful? Give feedback.
-
Not that Lit creates observed attributes by default, but does not reflect properties to attributes by default. We do this because so many reactive properties are simple types that we can deserialize to properties and letting them be set by attributes has no cost and makes the components more usable to plain HTML consumers. We don't reflect by default because there is a performance cost to it and ideally attributes would be "owned" and set only by their container, not the component itself. Reflected attributes are mostly needed for styling, so we want people to choose which properties should be reflected carefully. We also have So regarding just the default to observe attributes: I'd say that the first point is true: for complex-valued objects there isn't a great default to deserialize, so I do end up with some The easier part I don't think is true because from the component POV it is the property being set - Lit takes care of that. The performance part isn't true because there's already a generic attributeToProperty function - marking a property as settable as an attribute doesn't add any code or compute cost when it's not used. |
Beta Was this translation helpful? Give feedback.
-
I've generally steered clear of attributes for the most part:
.propName=
syntaxI'm coming from using FAST Element: the way it works there is you can expose a property with
@observable
or in addition expose it as an attribute with@attr
.So I was a bit surprised to find that Lit exposes all properties as attributes by default. I'm going to need to litter my code with
@property({ attribute: false })
all over the place. I can also imagine problems with component authors unwittingly exposing attributes with odd or unhelpful squashed-down names likesomepropertyhere
, then having issues with backwards-compatibility if they want to fix them.I wanted to see how others approach things: do people make heavy use of the attributes?
Beta Was this translation helpful? Give feedback.
All reactions