-
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
Changes from all commits
1f7c81d
c6c7df6
8cf72b8
d1379b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,13 +1,15 @@ | ||
import React from "react"; | ||
import TextWidget, { TextWidgetProps } from "../TextWidget"; | ||
import { WidgetProps } from '@rjsf/core'; | ||
|
||
const DateWidget = (props: TextWidgetProps) => { | ||
const DateWidget = (props: WidgetProps) => { | ||
const { registry } = props; | ||
const { TextWidget } = registry.widgets; | ||
return ( | ||
<TextWidget | ||
{...props} | ||
{...props} | ||
type="date" | ||
/> | ||
); | ||
}; | ||
|
||
export default DateWidget; | ||
export default DateWidget; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,9 @@ | ||
import React from "react"; | ||
import TextWidget, { TextWidgetProps } from "../TextWidget"; | ||
import { WidgetProps } from '@rjsf/core'; | ||
|
||
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 commentThe reason will be displayed to describe this comment to others. Learn more. @epicfaace This is one place where type is passed... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, this makes sense now |
||
}; | ||
|
||
|
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 thetype
prop? And would it be better / equivalent / more consistent to change this line of code to not usetype
, 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 theTextWidgetProps
there have been expanded to include the@material-ui
TextField
props, so passingtype
in works there (sadly I spent a decent amount of time trying to apply a similar solution tobootstrap-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 whatfluent-ui
does with type forbootstrap-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 theFieldProps
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 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.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 using the catch-all is OK for this PR.
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.