-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Add TS support to fields #8863
Add TS support to fields #8863
Conversation
a7585f3
to
e0724b5
Compare
61a7dd6
to
97ab048
Compare
60f770e
to
c29b020
Compare
}; | ||
ArrayFieldImpl.propTypes = fieldPropTypes; |
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 used to clone the prop types before. There was probably a reason, I think you shouldn't change that.
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 can't think of a valid reason. We do the same in EmailField.
I think someone did not simplify the syntax when removing an old propType specific to the ArrayField that did not make sense in v4. See f7d9f18
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 vaguely remember having to clone proptypes for an obscure reason. Let's revert it if we have no reason to do 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.
What about the EmailField, UrlField and WrapperField then?
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.
Let's keep them as in master. I know, in master there is no consistency. Let's keep it like that.
My opinion is that this PR changes quite a lot of stuff, and we should avoid all unnecessary changes to reduce any potential BC break.
Just upgraded from 4.5.1 to 4.11.1 and having TS issues all over the place where I set my "source" parameter, is there a way to disable this? |
@akillingbeck89 This change should be backwards compatible. If it is not, this is to be considered as a bug. |
Dont have time right now, will do it next week, but no custom types are being passed and an example error I'm getting is: Type '"channelId"' is not assignable to type ' |
How did you fix this issue? |
Follow #8862
If users provide types extending
RaRecord
, nothing changes, they won't have TS validation of thesource
prop but they won't have any error either. Same when they don't provide types.If users provide types that don't extend
RaRecord
, they'll get validation and completion on thesource
prop