refactor(signal-forms): unify how users access metadata added with define and metadata
#62656
Conversation
| @@ -74,5 +70,5 @@ export function defineResource<TValue, TData, TRequest, TPathKind extends PathKi | |||
| const pathNode = FieldPathNode.unwrapFieldPath(path); | |||
| pathNode.logic.addDataFactory(key, factory); | |||
|
|
|||
| return key as DataKey<ResourceRef<TData | undefined>>; | |||
| return key as StaticMetadataKey<ResourceRef<TData | undefined>>; | |||
There was a problem hiding this comment.
Where does the undefined come from / why is it necessary?
Both the opts.asKey and default value are just ResourceRef<TData>.
There was a problem hiding this comment.
If the schema doesn't set a particular static key for a particular field, but we try to read it: f().metadata(KEY) it returns undefined. This doesn't happen for reactive ones, because for those the key itself holds a default value to use in the case that the schema didn't define it at all for that field. Since the reactive ones represent reduced values, its basically the default case of reducing an empty list
| * If the metadata is not defined for a given field, its value is undefined. | ||
| */ | ||
| export class StaticMetadataKey<TValue> extends KeyCtor<TValue> { | ||
| protected constructor() { |
There was a problem hiding this comment.
Any reason why these are protected while MetadataKey's constructor is private?
There was a problem hiding this comment.
private prevents extending it, and we don't really want people to extend the base class. (We only know how to handle these two types of metadata)
63b4448
into
angular:prototype/signal-forms
Eliminates
DataKeyandFieldState.dataas a separate user concept from metadata.DataKeyis nowStaticMetadataKeyand is accessed viaFieldState.metadatathe same way as wthReactiveMetadataKey. Note the there are still separate logic functions (define()andmetadata()) for registering static and reactive metadata to a field. I'll try to unify the way they're created in a followup PR.