-
-
Notifications
You must be signed in to change notification settings - Fork 526
feat: Allow restricting field component to field value #1606
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
base: main
Are you sure you want to change the base?
Conversation
|
Command | Status | Duration | Result |
---|---|---|---|
nx affected --targets=test:sherif,test:knip,tes... |
❌ Failed | 29s | View ↗ |
nx run-many --target=build --exclude=examples/** |
❌ Failed | 4s | View ↗ |
☁️ Nx Cloud last updated this comment at 2025-10-05 12:25:05
UTC
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1606 +/- ##
===========================================
- Coverage 89.55% 43.03% -46.52%
===========================================
Files 34 13 -21
Lines 1493 158 -1335
Branches 370 26 -344
===========================================
- Hits 1337 68 -1269
+ Misses 139 79 -60
+ Partials 17 11 -6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Wow. You'd think if one misclick is able to mark a PR as ready for review, you'd have the option to mark it as draft on mobile. Doesn't seem to be possible. I'll mark it as draft again when I'm on desktop ... |
The current implementation works great for simple types, and I could certainly make use of it for my most common form fields to cut down on some boilerplate and current need to pass What were you wondering about specifically in terms of generics? I've had a play with trying to register a generic form components similar to After registering the component, it's fairly straightforward to define various simple data shapes that extend However, the component ends up locked to a strict option type of I'm no library-level TS wizard so I'm a bit grasping at straws for we'd ever be able to inject the correct type values into these generic components at the |
You mean a case where the component has properties that should adapt to the field value using it? Yeah, that is very difficult in the current iteration of this PR, which is why it has been stale while I consider some other options. A simple example of this would also be Radio buttons. The |
Yes, Radio and a basic Select (constrained to a string union) are simpler examples of the challenges here. This crude API seems to work in my application code, the challenge would obviously be to feed
For this UI element:
|
Sounds interesting! After some other PR work, I'll freshen this one up a bit and see if I can find a nice solution for it. |
|
Related issue: #1506
This PR implements a way to create 'branded' field components. Those special field components may only be used if the
AppField
's value matches it.TODOS
The issue
The solution
The PR addresses it as follows (feedback is appreciated!):