refactor(signal-forms): rework metadata API #62713
Conversation
Co-authored-by: michael-small <33669563+michael-small@users.noreply.github.com>
| export class Property<TValue> { | ||
| private brand!: TValue; | ||
|
|
||
| protected constructor() {} |
There was a problem hiding this comment.
This is done for consistency with AggregateProperty which is constructed via static factory methods. Can you elaborate on why? I'm not necessarily against it, just curious why its important to you.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This is a great refactoring that significantly improves the clarity and consistency of the API by renaming "metadata" to "property". The introduction of Property and AggregateProperty classes, along with the new property and aggregateProperty functions, makes the system more explicit and easier to understand. The removal of the old metadata and data APIs cleans up the codebase nicely.
I've found a couple of minor areas for improvement:
- The JSDoc for the new
propertyfunction could be enhanced to better document its overloads. - There appears to be some unused code in the new
FieldPropertyStateclass that can be removed.
Overall, this is a high-quality change that moves the signal-based forms in the right direction.
e96d9e3
into
angular:prototype/signal-forms
* rename metadata key types * fix metadata reduce to not confuse item and acc types * remove defineComputed, defineResource * rename define and meatdata logic binding fns * move setMetadata next to addToMetadata * address comments Co-authored-by: michael-small <33669563+michael-small@users.noreply.github.com> * pattern cleanup * rename metadata concept to property * consolidate field property state * rename metadata.ts to property.ts * add 2-param variant of property rule * rename getDefault to getInitial for alignment with standard reduce * address ai review --------- Co-authored-by: michael-small <33669563+michael-small@users.noreply.github.com>
Note: each commit is an independently reviewable step if you prefer to review commit-by-commit.
I still have a few open questions:
metadataorpropertyfor this concept?Decided on slight preference for
propertybecause it better conveys that these things can be used to drive actual schema logicWhat should be the names of the functions used to bind logic to
MetadataKeyandAggregateMetadataKey.Some ideas for
MetadataKeyinclude:metadata(orproperty)setMetadata(orsetProperty)Some ideas for
AggregateMetadataKeyinclude:addMetadata(oraddProperty)addToMetadata(oraddToProperty)aggregateMetadata(oraggregateProperty)accumulateMetadata(oraccumulateProperty)contributeMetadata(orcontributeToProperty)Decided to go with
propertyandaggregatePropertyfor now, seems clear and matches the class namesMetadataKey.create<...>()for a key that you use internally to the schema. I'm worried people will just yolo andMetadataKey.create<any>(), should we add back an equivalent to the 2-parameter variant ofdefine?Decided yes, will introduce 2-parameter variant of property (
const PROP = property(p.whatever, () => ...))