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
PR for #1647 - add ui:props to all material-ui widgets #1672
Conversation
/> | ||
} | ||
label={label} | ||
label={label || schema.title} |
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.
Added the "schema.title" to be aligned with the rest of the widgets
control={checkbox} | ||
key={index} | ||
label={option.label} | ||
/> | ||
) : ( |
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.
This code is duplicated with no reason
@@ -41,13 +42,14 @@ const RangeWidget = ({ | |||
//error={!!rawErrors} | |||
required={required} | |||
> | |||
<FormLabel id={id}>{label}</FormLabel> | |||
<FormLabel id={id}>{label || schema.title}</FormLabel> |
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.
Added the "schema.title" to be aligned with the rest of the widgets
@@ -33,7 +36,7 @@ const UpDownWidget = ({ | |||
//error={!!rawErrors} | |||
required={required} | |||
> | |||
<InputLabel>{label}</InputLabel> | |||
<InputLabel>{label || schema.title}</InputLabel> |
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.
Added the "schema.title" to be aligned with the rest of the widgets
return inline ? ( | ||
<FormControlLabel | ||
|
||
return <FormControlLabel | ||
control={checkbox} | ||
key={index} | ||
label={option.label} |
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.
Is this missing the || schema.title
that was added in all the other places on purpose?
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.
No, you can find this in line 62 - it's part of the FormLabel
, not as part of the FormControlLabel
@epicfaace any update on this one? I'm not so sure why it didn't get into v2-alpha5 |
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.
Sorry it took some time to get to this.
- Can you add some tests that verify this functionality (both the ui:props and schema.title overrides)? You could just extend the snapshot tests that are already in the material-ui folder.
- I'm worried that people may use
ui:props
to override fields that we don't want the user to override, such as, for example,required
,id
, oronChange
(to override these ones, it really might be best to make a custom widget). Perhaps we should define a list of overridable props for each widget usingui:props
and only override those. What do you think?
One suggestion is to pull out the |
Hello, any update on this? |
@dekelb just thought of another thing -- what if someone inputs I'm thinking it would be best if, for each widget, we could define a whitelist of props that could be overridden using |
Hi, I'm trying to figure out how I could use the variant prop and other adjustments to my schema with material-ui. Could it be an idea like @epicfaace mention to whitelist at least the props that has something to do with the design in the material-ui doc? https://material-ui.com/api/text-field/ |
Any progress on this PR? |
We need to add a whitelist for allowed props. See how it was done with the fluent ui theme. |
Why do you need an allowlist? Just let all props through, if they do something or not, it doesn't hurt and it will work when upstream adds new props automatically. |
Why would that someone not validate and escape user input correctly as you would always do it with any kind of user input?
The list will change constantly. It should just let extra props through that it doesn't know. It's a common scheme to let pass all other props down in the hierarchy. |
PS: Check out upstream: https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/TextField/TextField.js |
One use case of react-jsonschema-form is allowing users to specify and save their own JSON Schemas (which I use myself in a form builder). It doesn't seem trivial to validate that input; at least, there don't exist libraries that could do that automatically (something like XSS sanitizers) and it would require you to perform the validation yourself. The current behavior of react-jsonschema-form is that no possible JSON Schema / uiSchema can have a security impact, because there's no way to set the dangerouslyInnerHTML prop. With this change, this guarantee changes, because suddenly uiSchemas become untrusted user input and can cause XSS vulnerabilities. At the very least, this would be a backwards incompatible change. |
Hi, any update on this? Still waiting on the whitelisting? |
While this one is seems to be dead, can you pass rest props to all components like you do here https://github.com/rjsf-team/react-jsonschema-form/blob/master/packages/material-ui/src/TextWidget/TextWidget.tsx#L53 |
Currently I can do something like this with TextWidget and I'd like to be able to do this for other widgets as well:
|
@wight554 sorry I don't understand what you are proposing, could you provide more details? |
The idea was to add props spreading to all widget components |
Ok. Why do you think it would be safe enough in this case? |
There's no way to pass these, unless you wrap component with some hoc |
This issue has been automatically marked as possibly close because it has not had recent activity. It will be closed if no further activity occurs. Please leave a comment if this is still an issue for you. Thank you. |
This issue was closed because of lack of recent activity. Reopen if you still need assistance. |
This PR is a fix for issue #1647
Following the comments in the issue - it seems like the best option was to use the "ui:props" inside the uiSchema (of each field), which being pushed into the "options" variable inside the widget (as part of the WidgetProps).
The reason I decided to use the "ui:props" and not just add properties directly to the "options" is that some of those properties are already being used, and this might cause issues there.
Also - those properties are relevant specifically to the Components that we take from the Theme. I noticed some requests to also support Fields/Components from other libs - using this standard we will be able to support other field-specific properties.