feat: add readonly flag
#92
Conversation
| /** | ||
| * Whether the attribute is read-only. | ||
| */ | ||
| readonly?: boolean; |
There was a problem hiding this comment.
What does it mean for an attribute to be read-only? afaiu, there really shouldn't be such a thing.
If there's a use for this, say to cover for the lack of CSS custom state, should we highlight that in the description?
There was a problem hiding this comment.
an element might observe changes in that attribute and reject values it finds icky, resetting to the previous known-good value, or removing the attribute.
There was a problem hiding this comment.
@justinfagnani Would this PR be clear to merge if it was only adding this to properties? I can create a new PR if necessary, but it would be nice to get this added for properties to unblock the CEM analyzer support. If @bennypowers or others feel strongly about usage with attributes, perhaps we can create a new issue for that discussion?
There was a problem hiding this comment.
If youre using @custom-elements-manifest/analyzer, you can already support this via a plugin
There was a problem hiding this comment.
I would go with this if it were for properties only to avoid semantics questions about "readonly" attributes.
There was a problem hiding this comment.
@thepassle one tool emitting this property doesn't mean that other tools know to read it.
There was a problem hiding this comment.
True, but they mentioned cem analyzer being blocked, which it isnt
There was a problem hiding this comment.
Thanks to both of you for the responses. I am using that analyzer, and was able to find the plugin, so that does unblock me personally. My use case for this particular feature is Angular Framework integration, and I need to ensure that readonly properties can't be bound as an @Input().
I do still think it would be a good addition to the spec, so I'll try to get a PR up soon. Enough people have asked and it encodes a real semantic of the language. If it were added here, support could be added to the analyzer without a plugin, and other tools as well.
There was a problem hiding this comment.
Id be okay with adding readonly for fields, im also unsure about attributes. Perhaps we can indeed address that in a separate discussion.
@MikeMatusz If and when that change has landed in the schema, would you be willing to contribute your plugin logic to cem/a?
There was a problem hiding this comment.
It's not actually my logic, the original author of this PR appears to have written the plugin I found (https://github.com/bennypowers/cem-plugins/tree/main/plugins/cem-plugin-readonly), but I'd be more than willing to help contribute it to cem/a unless @bennypowers would prefer to do it himself. This spec and that analyzer have proven extremely useful to me.
|
I'm still interested in discussing this, though it might be best in an issue. I'm mostly concerned with defining the semantics of "read only" attributes, since they technically don't exist in HTML. Under what conditions should tools add this flag? What behavior do we expect for tools that read it? I wonder if it would be better named "output" or something similar - meaning that the element writes to the attribute (even though ideally they don't, but there are several reasons to at the moment, ie styling) so hosts of the element should not write to it. |
Closes #34