Closed 43081j closed 4 years ago
You should be able to access the decorator through member.meta
which is of the following type:
interface LitElementPropertyConfig {
type?: SimpleType | string;
attribute?: string | boolean;
node?: {
type?: Node;
attribute?: Node;
decorator?: CallExpression;
};
hasConverter?: boolean;
default?: unknown;
reflect?: boolean;
}
So you would be able to check for member.meta?.node?.decorator?.identifier.text
to get the name of the decorator :+1:
i updated it, didn't realise you could access the typescript node there.
remember this is based on 1.2.0 too FYI
edit: it works, but i used member.node
rather than member.meta.node.decorator
. is there any particular reason you have both? this way we can tolerate multiple decorators and still match...
member.node
is the node where the property/attribute was found/emitted. This could be a PropertyDeclaration
, ExpressionStatement
, PropertyAssignment
, eg. depending on how it was found.
member.meta
contains specific metadata of the analysis of the property/attribute. This data-structure right now only contains lit-specific information, but I plan that this data-structure in the future could depend on the specific WCA
-flavor that emitted it. For example, if there was to be created a Stencil-specific WCA
-flavor, the meta-field would contain Stencil
-specific data.
member.meta.node.decorator
will always point to the decorator that contains LitElement
-specific metadata which was found during the analysis of the PropertyDeclaration
. The decorator would always be either a property
- or internalProperty
-CallExpression
and other decorators would be ignored. If there are multiple decorators, this would still be either the property
or internalProperty
decorator. The loop over member.node.decorators
has already been done in WCA
and the decorator of interrest would be assigned to member.meta.node.decorator
, so you can trust the text
property of that node to be internalProperty
when that's the case.
i updated it. just wasn't aware what the meta node was so thanks for the explanation. i do wonder what'll happen when one day multiple decorators might become a thing in lit, though. maybe it should be an array rather than assuming there will always be just one "useful one" per property.
this tries to do something along the lines of what #79 wanted i guess.
this bit is questionable:
to detect if
@internalProperty
was used. it is upto you if you want to introduce something in WCA so component members have an explicit flag when they use that decorator. this should work fine though since making a property not use attributes is close enough to being internal anyway.