Skip to content

refactor(signal-forms): more ergonomic metadata key creation #62653

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 16, 2025

Conversation

mmalerba
Copy link
Contributor

No description provided.

@mmalerba mmalerba requested review from leonsenft, kirjs and alxhub July 15, 2025 20:31
@mmalerba mmalerba added area: forms target: feature This PR is targeted for a feature branch (outside of main and semver branches) labels Jul 15, 2025
@ngbot ngbot bot modified the milestone: Backlog Jul 15, 2025
Copy link
Contributor

@leonsenft leonsenft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Why are we renaming the exported type from MetadataKey to ReactiveMetadataKey?
  • Could you please elaborate on how this change makes things more ergonomic in the commit description. It's not immediately clear to me how and there's no test/examples demonstrating the change.

@mmalerba
Copy link
Contributor Author

Why are we renaming the exported type from MetadataKey to ReactiveMetadataKey?

I plan to get rid of DataKey as a distinct thing from MetadataKey and instead make it StaticMetadataKey while the thing we used to call just MetadataKey is now ReactiveMetadataKey, but I'm saving that for a followup PR

Could you please elaborate on how this change makes things more ergonomic in the commit description. It's not immediately clear to me how and there's no test/examples demonstrating the change.

Its more ergonomic because you don't have to pass two functions every time you create a metadata key. If you're using one of the built in patterns of reducing the values (e.g. aggregate, min, max) you can just say MetadataKey.aggregate<string>() instead of reimplementing the logic to reduce to an array of strings. You can see what this looks like for our predefined keys REQUIRED etc. Those define our built in metadata keys, but a user would have to do a similar thing to make their custom metadata keys

@mmalerba mmalerba requested a review from leonsenft July 15, 2025 21:10
@mmalerba
Copy link
Contributor Author

/gemini review

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the creation of metadata keys to be more ergonomic by introducing a factory pattern on the MetadataKey class. My review includes a few suggestions for minor improvements, such as fixing typos in comments, enhancing readability, and a potential performance optimization in the pattern validator.

@mmalerba mmalerba merged commit 74d83f4 into angular:prototype/signal-forms Jul 16, 2025
11 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: forms target: feature This PR is targeted for a feature branch (outside of main and semver branches)
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants