-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
bootstrap-4 TextWidget wrappers now pull from registry, add rootSchema to Registry, Fix FieldProps.onFocus type to match WidgetProps #2519
Conversation
…port `TextWidget` from the source hierarchy, instead pull from the `registry.widgets` - These changes allow all of these `TextWidget` wrappers (like `EmailWidget`, etc...) to immediately use a custom `TextWidget` class - Updated the `Registry` type in the `core/index.d.ts` file to add `rootSchema` - This fixed a TODO and avoids the need to cast `registry` to any in the three typescript `ArrayFieldTemplate` implementations - Also updated `WidgetProps` to add an optional `type` - This eliminated the custom `TextWidgetProps` for `bootstrap-4` which prevented a previous PR from converting the `TextWidget` wrappers - Updated all of the `bootstrap-4` widgets to use `TextWidget` from the registry, using simple `WidgetProps` - Updated `TextWidget` to remove `TextWidgetProps` and to simply use `WidgetProps` - Updated the `material-ui` `UpDownWidget` tests to add a blank `rootSchema` to the `registry` - Updated the `bootstrap-4` `createMock()` to add a blank `rootSchema` to the `registry` as well as adding `TextWidget` to the `registry.widgets`
@epicfaace I figured out how to fix |
- Made the `FieldProps.onFocus` match the definition of `WidgetProps.onFocus` to avoid type conversion error when creating custom components
@epicfaace I imagine you are rather busy... Is there another person who you know of who can complete this review? |
Maybe @jimmycallin?
…--
Ashwin Ramaswami
On Thu, Aug 19, 2021 at 12:37 PM Heath C ***@***.***> wrote:
@epicfaace <https://github.com/epicfaace> I imagine you are rather
busy... Is there another person who you know of who can complete this
review?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2519 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4MX4EBVJDKMUSQ3KGZE3T5UXLPANCNFSM5CKPPZWA>
.
|
@epicfaace or @jimmycallin I'd love to be able to merge these changes. I hope one of you two can complete the review soon |
@epicfaace Is there one or two other PRs that I could review for you in return for a review on this? Are you worried about the type changes causing problems? |
@@ -36,7 +32,7 @@ const TextWidget = ({ | |||
target: { value }, | |||
}: React.FocusEvent<HTMLInputElement>) => onFocus(id, value); | |||
const inputType = (type || schema.type) === 'string' ? 'text' : `${type || schema.type}` |
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 one thing remaining is that I'm a bit confused as to why TextWidget uses the type
prop, but only in the bootstrap-4 theme. Could you point me to the code that actually passes the type
prop? And would it be better / equivalent / more consistent to change this line of code to not use type
, in favor of something like this (https://github.com/rjsf-team/react-jsonschema-form/blob/master/packages/fluent-ui/src/TextWidget/TextWidget.tsx#L73)?
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 type prop is also used in the @material-ui
theme... but the TextWidgetProps
there have been expanded to include the @material-ui
TextField
props, so passing type
in works there (sadly I spent a decent amount of time trying to apply a similar solution to bootstrap-4
with no success :( ). See https://github.com/rjsf-team/react-jsonschema-form/blob/master/packages/material-ui/src/TextWidget/TextWidget.tsx#L11. I'm not against doing what fluent-ui
does with type for bootstrap-4
if that feels more comfortable for you.
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 am curious if you feel like the WidgetProps
should be restricted to only those current props defined on it, unlike the FieldProps
which has the catch-all "other props" [prop: string]: any;
defined on 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.
Honestly, with the change to WidgetProps
that I'm proposing, I could probably remove the override that material-ui
has since the catch-all would do the same thing. Heck, most of the code between the three packages for the TextWidget
overrides could probably be standardized into the same exact code (most of which very closely matches how core
does it)... which makes me wonder whether it makes sense to do a bit more work in core to use TextWidget
rather than BaseInput
... or make all three Typescript implementations simple provide their TextWidget
implementation as the BaseInput
and remove all the overrides that are simply the override the "type"
since thats what core
already does.
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 am curious if you feel like the
WidgetProps
should be restricted to only those current props defined on it, unlike theFieldProps
which has the catch-all "other props"[prop: string]: any;
defined on it?
I think using the catch-all is OK for this PR.
Honestly, with the change to
WidgetProps
that I'm proposing, I could probably remove the override thatmaterial-ui
has since the catch-all would do the same thing. Heck, most of the code between the three packages for theTextWidget
overrides could probably be standardized into the same exact code (most of which very closely matches howcore
does it)... which makes me wonder whether it makes sense to do a bit more work in core to useTextWidget
rather thanBaseInput
... or make all three Typescript implementations simple provide theirTextWidget
implementation as theBaseInput
and remove all the overrides that are simply theoverride the "type"
since thats whatcore
already does.
Yeah, if you'd like to do additional refactoring, that would also be good. Let's not do it in this PR, though, maybe in a separate PR if you are interested in doing it.
const URLWidget = (props: TextWidgetProps) => { | ||
const URLWidget = (props: WidgetProps) => { | ||
const { registry } = props; | ||
const { TextWidget } = registry.widgets; | ||
return <TextWidget {...props} type="url" />; |
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.
@epicfaace This is one place where type is passed... material-ui
uses the same exact pattern. fluent-ui
chose to put type
into the ui:options.props
and then extracts it on the line above what you mentioned, filters out non-fluent props and spreads it over the default type
that is being extracted on the line you mentioned.
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.
Thanks, this makes sense now
const URLWidget = (props: TextWidgetProps) => { | ||
const URLWidget = (props: WidgetProps) => { | ||
const { registry } = props; | ||
const { TextWidget } = registry.widgets; | ||
return <TextWidget {...props} type="url" />; |
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.
Thanks, this makes sense now
@@ -36,7 +32,7 @@ const TextWidget = ({ | |||
target: { value }, | |||
}: React.FocusEvent<HTMLInputElement>) => onFocus(id, value); | |||
const inputType = (type || schema.type) === 'string' ? 'text' : `${type || schema.type}` |
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 am curious if you feel like the
WidgetProps
should be restricted to only those current props defined on it, unlike theFieldProps
which has the catch-all "other props"[prop: string]: any;
defined on it?
I think using the catch-all is OK for this PR.
Honestly, with the change to
WidgetProps
that I'm proposing, I could probably remove the override thatmaterial-ui
has since the catch-all would do the same thing. Heck, most of the code between the three packages for theTextWidget
overrides could probably be standardized into the same exact code (most of which very closely matches howcore
does it)... which makes me wonder whether it makes sense to do a bit more work in core to useTextWidget
rather thanBaseInput
... or make all three Typescript implementations simple provide theirTextWidget
implementation as theBaseInput
and remove all the overrides that are simply theoverride the "type"
since thats whatcore
already does.
Yeah, if you'd like to do additional refactoring, that would also be good. Let's not do it in this PR, though, maybe in a separate PR if you are interested in doing it.
I am interested in doing it... Do I need an issue for that or just push a PR when it's ready? |
That'd be great! An issue is not required, but it might be nice to make an issue if it doesn't take too much time so it's easier to organize what work is going to be done. |
Reasons for making this change
TextWidget
wrappers (likeEmailWidget
, etc...) to immediately use a customTextWidget
classRegistry
type in thecore/index.d.ts
file to addrootSchema
and fix the indentingregistry
toany
in the three typescriptArrayFieldTemplate
implementationsFieldProps['registry']
withRegistry
now that a separate type existsWidgetProps
to add a generic[prop: string]: any
just likeFieldProps
hasTextWidgetProps
forbootstrap-4
which prevented a previous PR from converting theTextWidget
wrappersFieldProps.onFocus
match the definition ofWidgetProps.onFocus
to avoid type conversion error when creating customField
components that passonFocus
to aWidget
bootstrap-4
widgets to useTextWidget
from the registry, using simpleWidgetProps
TextWidget
to removeTextWidgetProps
and to simply useWidgetProps
material-ui
UpDownWidget
tests to add a blankrootSchema
to theregistry
bootstrap-4
createMock()
to add a blankrootSchema
to theregistry
as well as addingTextWidget
to theregistry.widgets
If this is related to existing tickets, include links to them as well. Use the syntax
fixes #[issue number]
(ex:fixes #123
).Fixes #2512 for
bootstrap-4
Checklist