-
Notifications
You must be signed in to change notification settings - Fork 1
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
Support field type #3
Conversation
View your CI Pipeline Execution ↗ for commit ee4cb61.
☁️ Nx Cloud last updated this comment at |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3 +/- ##
=======================================
Coverage ? 45.73%
=======================================
Files ? 18
Lines ? 2003
Branches ? 123
=======================================
Hits ? 916
Misses ? 1087
Partials ? 0 ☔ View full report in Codecov by Sentry. |
d5751bf
to
4ed98c7
Compare
🦋 Changeset detectedLatest commit: 8577a48 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
dd7aef7
to
0424867
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are some fairly major changes that need to happen here. I feel we shouldn't expose the element type to the developer. This is why each field should have an inputType
key that just suggests something is SINGLE_SELECT
or MULTI_SELECT
. Whether it's a dropdown or radio doesn't really matter.
Let's talk about this in standup on Tuesday.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove the -d
from the filename? I would think types.test
would be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can, however this is a convention of vite. https://vitest.dev/guide/testing-types
it specifically calls tsc under the hood, if we use test
I think it may confuse how the file should be run/ executed.
export type InferSingleValueCollectorFromSingleValueCollectorType< | ||
T extends SingleValueCollectorTypes, | ||
> = T extends 'TextCollector' | ||
? TextCollector | ||
: T extends 'DropDownCollector' | ||
? DropDownCollector | ||
: T extends 'ComboboxCollector' | ||
? ComboboxCollector | ||
: T extends 'RadioCollector' | ||
? RadioCollector | ||
: //: T extends 'LabelCollector' | ||
//? LabelCollector | ||
T extends 'PasswordCollector' | ||
? PasswordCollector | ||
: T extends 'FlowLinkCollector' | ||
? FlowLinkCollector | ||
: /** | ||
* At this point, we have not passed in a collector type | ||
* or we have explicitly passed in 'SingleValueCollector' | ||
* So we can return either a SingleValueCollector with value or without value | ||
* or without a value. | ||
**/ | ||
| SingleValueCollectorWithValue<'SingleValueCollector'> | ||
| SingleValueCollectorNoValue<'SingleValueCollector'>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what to think of this. Is this a recommended pattern that I'm just unfamiliar with, or is there some requirement we have that necessitates such a complex, deeply nested structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason i created this type was to better infer the type.
I definitely do not claim this to be the best way to do it, and if you feel there is not enough value derived from this, we can ignore it.
But i'd like to hear your thoughts outside of just purely this type, if you think the value it provides is worth the "complexity" of the type. (its just how we can write "if else" in types)
import { | ||
type ActionCollectors, | ||
type ActionCollectorTypes, | ||
type InferSingleValueCollectorFromSingleValueCollectorType, | ||
type SingleValueCollectorTypes, | ||
} from './collector.types'; | ||
import type { DaVinciField } from './davinci.types'; | ||
import type { | ||
Combobox, | ||
DaVinciField, | ||
//LabelField, | ||
Radio, | ||
StandardFieldValue, | ||
} from './davinci.types'; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the two imports use different conventions even though they are both importing types. Can you change the first to import type {} from 'module'
, like you have the second import?
initial commit to start types for fields
adding support for form-field components
updating a few configurations in new repo for davinci app
adding a changeset and a few fixes to the repo for adding a changeset
0424867
to
81efc38
Compare
adds types test files for many of the types files we have.
81efc38
to
ae848c8
Compare
update pr comments and fix a few areas where type was wrong still
e451111
to
56e964d
Compare
@@ -118,6 +122,7 @@ export async function davinci({ config }: { config: DaVinciConfig }) { | |||
return function () { | |||
console.error('Collector not found'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
obviously this was here, just want to make sure we want a console.error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we should probably talk about this. Ultimately, I think it's good we log errors when they happen, but we probably need to add a control for this sometime soon (like logLevel). And, we should be consistent with it. I think some instances of errors we don't log with error
.
}; | ||
|
||
export type Radio = { | ||
inputType: 'SingleSelect'; | ||
export type SingleSelect = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha so these are "the same" type.
I wonder how this narrows, i'll read through a test.
I think it should narrow without a generic but my brain is questioning it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand your comment. Can you elaborate?
728520e
to
b785213
Compare
b785213
to
8577a48
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the duplicate entry in .changeset/config.json
, this looks good.
.changeset/config.json
Outdated
"linked": [], | ||
"access": "public", | ||
"baseBranch": "main", | ||
"updateInternalDependencies": "patch", | ||
"ignore": [ | ||
"@forgerock/*", | ||
"@forgerock/mock-api-v2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ryanbas21 I'm sure you didn't intend to change this to something else?
@@ -118,6 +122,7 @@ export async function davinci({ config }: { config: DaVinciConfig }) { | |||
return function () { | |||
console.error('Collector not found'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we should probably talk about this. Ultimately, I think it's good we log errors when they happen, but we probably need to add a control for this sometime soon (like logLevel). And, we should be consistent with it. I think some instances of errors we don't log with error
.
}; | ||
|
||
export type Radio = { | ||
inputType: 'SingleSelect'; | ||
export type SingleSelect = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand your comment. Can you elaborate?
JIRA Ticket
https://pingidentity.atlassian.net/browse/SDKS-3655
Description
Adds support for a few fields from davinci connectors like dropdown, radio, flowlink, etc.