rjsf-team / react-jsonschema-form Goto Github PK
View Code? Open in Web Editor NEWA React component for building Web forms from JSON Schema.
Home Page: https://rjsf-team.github.io/react-jsonschema-form/
License: Apache License 2.0
A React component for building Web forms from JSON Schema.
Home Page: https://rjsf-team.github.io/react-jsonschema-form/
License: Apache License 2.0
Can you provide a suggestion on what DatePicker that supports range select can be used with the plugin?
If no explicit default is provided, if no action was made by the user, then we should set the default form data value for that field to the first item of the enum.
(splitted out from #25)
Example in http://json-schema.org/example2.html shows an enum
field doesn't seem to require a type
property defined:
"fstype": {
"enum": ["ext3", "ext4", "btrfs"]
},
I'm trying to combine two JSON schemas together like so:
let schema = {
type: 'object',
anyOf: [
schema1,
schema2,
],
}
Doesn't look like this is supported, or did I miss it? Any plans to add support?
We should probably offer support for enumNames
, which is draft v5 atm:
"obj": {
"enum": [{a: 1}, {b: 1}, {c: 1}],
"enumNames": ["a", "b", "c"]
}
I'm trying to use a stateless widget like so:
'ui:widget': (props) ->
<input type="checkbox" id="ID"/><label htmlFor="ID">I agree</label>
The issue is generating the ID. I could obviously use a real component and do it inside the component. I could hope the component only loaded once (ouch). I could also probably hack the onChange into the onClick of the label. But all of those options aside, would it make sense for the package to generate a unique ID for each field and pass it in? _.uniqueId()
maybe?
It would be nice to pass a custom validator instance. One could define custom validations on that instance. I can submit a PR if needed:)
In some cases it would be nice to be able to provide labels instead of the strings true
and false
. The simplest example being Yes
and No
in English. I wonder if it would be practical to add this to the uiSchema
definition? As far as I know, JSON schema doesn't provide this support.
node --version: v5.5.0
npm --version: 3.5.3
The error:
[email protected] /Users/mathieu/mozilla/kinto-admin
├── UNMET PEER DEPENDENCY history@^1.17.0
└─┬ [email protected]
└── [email protected]
npm WARN [email protected] requires a peer of history@^1.17.0 but none was installed.
const uiSchema = {
foo: {
classNames: "a b c d"
}
}
After discussing it briefly with @almet and @magopian, I think we could offer an API to support themes.
A theme would be a way to define what the HTML semantics would be for rendering fields, a little what custom fields offer today, but it a more complete and generic way.
There would be a default theme, which would basically provide the same semantics as the ones we expose today.
Defining the theme to use would be done by providing an ui:theme
key at the root of the uiSchema
object:
const uiSchema = {
"ui:theme": "bootstrap"
};
A theme should be exposed in a requirable module, which name would be in the form react-jsonschema-form-theme-${themeName}
; eg.:
$ npm install react-jsonschema-form-theme-bootstrap --save
This would allow the community to create and share different themes.
Writing a theme would basically be matter of defining a set of custom fields and widget components for base jsonschema types:
const BootstrapSchemaField = (props) => {
const {schema, name, uiSchema, formData, widgets, required, onChange} = props;
return (
...
);
};
export default {
SchemaField: BootstrapSchemaField
};
Alternatively, we may rather want to expose hooks for defining SchemaField
's Wrapper
and ErrorList
inner component? Most theming would be about html semantics, class names and so on anyway.
Feedback welcome.
It seems to actually use the index rather than the text.
Loving this component so far! However, in my own usage, and even in the demo site, there's a noticeable lag when attempting to enter text into fields at a reasonable typing speed. Enabling the "trace react updates" option in Chrome React Developer Tools, it becomes apparent that the entire form is re-rendered any time an input changes.
I haven't dug into the code, but it would seem reasonable to implement shouldComponentUpdate
(perhaps simply with pure-render-mixin
) to prevent rerendering of components not affected by the change in form values.
I would like to be able to set a className on the <fieldset>
of my object fields.
My first guess was to try to use uiSchema
's classNames
so maybe it is the way to go.
What do you think about it ?
Link to the customization API documentation, explaining that it could be used to achieve some of the needs for theming.
Self-explanatory dream API:
import Form from "react-jsonschema-form";
const MyComponent = (props) => {
// ....
};
const schema = {
type: "string"
};
const widgets = {
myComponent: MyComponent
};
const uiSchema = {
"ui:widget": "myComponent"
};
render((<Form
schema={schema}
uiSchema={uiSchema}
widgets={widgets}
/>), document.querySelector("main"))
Context: as uiSchema
should be defined using JSON (and no necessarily JavaScript), we need to expose a way to register a custom component and associate it with a string unique identifier we can later reference from the JSON definition.
/cc @leplatrem
$ webpack
Hash: fa21190dc85f7f306103
Version: webpack 1.12.14
Time: 4517ms
Asset Size Chunks Chunk Names
personalDataComponent.js 890 kB 0 [emitted] personalDataComponent
+ 194 hidden modules
WARNING in /var/www/promo/~/react-jsonschema-form/~/deeper/index.js
Module not found: Error: Cannot resolve module 'buffertools' in /var/www/promo/node_modules/react-jsonschema-form/node_modules/deeper
@ /var/www/promo/~/react-jsonschema-form/~/deeper/index.js 14:21-43
There is some issue with deeper
dependency buffertools
. I get the following error message when trying to browserify:
Error: Cannot find module 'buffertools' from '.../node_modules/deeper
Therefore I can't get the JS bundle.
I am using
[email protected]
with
This "feature" makes it really hard to tweak the JSON data in the editors.
Right now validation errors are listed on top of the form, while we should obviously render them contextually at the field level.
This should be trivial as we have unique ids for each widget.
I want to use this project to extend existing forms but I cannot render the Form
component inside another form. The two solutions I see is to convert the existing form code into schema json and merge it with the user supplied schema OR have the option to render without the form tag. Merging the fields should work but there are cases where the existing form layout would be difficult to represent with ui schema and jsonschema (examples: an "advanced" section which collapses down, code editor with codemirror, and embedded previews next to fields). It seems having control over whether to render the form tag would be more robust.
It would be great to be able to use multiple buttons in the form. Maybe we could pass them via children ?
I need to be able to create select fields with the possibilty to select multiple values.
I can work on it but I'm not sure which way I should go with jsonschema.
My intuition is to use a schema that looks like this :
myField: { type: 'array', title: 'My field', items: { type: 'string', enum: ['foo', 'bar'], } }
maybe with an alternative widget multiselect
for example.
What are your opinions about this ?
I will probably also need to support enumNames (See https://github.com/json-schema/json-schema/wiki/enumNames-(v5-proposal) )
From the spec:
The value of "items" MUST be either an object or an array. If it is an object, this object MUST be a valid JSON Schema. If it is an array, items of this array MUST be objects, and each of these objects MUST be a valid JSON Schema.
{
"type": "array",
"items": [
{"type": "integer"},
{"type": "boolean"},
{"type": "string"}
]
}
Sample record:
[
-64586948,
true,
"dolor"
]
Note: This is a rather strange use case, and should be treated as P2.
Steps to reproduce:
Expected cause:
When change event occurs upon entering the decimal value, the value "3." will cast to integer value 3
, thus removing the decimal and preventing the user from entering their desired value.
In other words:
console.log( Number( '3.' ) );
// => 3
Is there a mechanism to support adding multiple sub forms? say to support one to many/many to many (or equivalent Nosql representation) relationships?
Any suggested path if someone to want to expand this project to do the same?
{
type: "object",
properties: {
firstName: {type: "string"}
}
}
The firstName field should have its label automatically set to firstName
by default.
This would be useful for the gh-pages live form builder, so one can alter the formData object and observe live form updates. That should be implemented through componentWillReceiveProps
.
Not sure if this is a bug or a feature, but if the schema requires a boolean value and this value is shown as a Checkbox, the validation always fails unless the box is checked.
I can see why it behaves like this, but my gut feeling says that when acheckbox is unchecked on a required boolean, the validation should pass and the value should be saved as false
.
Work-around: show the boolean in the uiSchema
as "ui:widget": "radio"
. This way you can explicitly
choose the false
value.
Another possible (untested) work-around:
{
"properties": {
"some_flag": { "enum": [ true, false ] }
}
}
But I think it should be the other way around: if it's required (even when false
), set it as required, it it has to be true, set "enum": [true]
for the field.
Is there an option we can pass to the ui schema that would result in a field being hidden?
Would it be the scope of this library to be able to specify small routines to compute default values of fields ?
Our use-cases is to be able to set the current date/time in a (hidden) field.
Reproduction from the example:
const schema = {
title: "Todo Tasks",
type: "object",
required: ["title"],
properties: {
title: {type: "object", title: "Title"},
done: {type: "boolean", title: "Done?", default: false}
}
};
The title
field has been changed to type: "object"
. This causes the package to throw unless there is a properties
key on the title
field. In my (admittedly very light) testing, the schema is valid without the properties
keyword, but I could be entirely wrong about that.
The error I see is Uncaught TypeError: Cannot convert undefined or null to object
. Adding properties: {}
solves the issue for me.
Not sure if this is really a bug or not. Although I guess there would be no harm in checking for the existence of properties
rather than assuming it exists. I'll see if I can find time to come up with a PR on that front if it would be helpful.
In current solution you always end up with button with label "Submit". It will be nice if you provide possibility of changing this label via "schema" object.
function MyCustomWidget(props) {
const {placeholder, value, defaultValue, required, onChange} = props;
return (
<div className="my-custom-widget">
<em>I am a custom widget with value {value}.</em>
<input type="text"
value={value}
defaultValue={defaultValue}
placeholder={placeholder}
required={required}
onChange={(event) => onChange(event.target.value)} />
</div>
);
}
const uiSchema = {
foo: {widget: MyCustomWidget}
}
This prevents dependant packages to use the lib with an error like this:
> [email protected] test /home/niko/work/kinto-admin
> NODE_ENV=test mocha --compilers js:babel/register --recursive --require ./test/setup-jsdom.js $(find test -name '*_test.js')
/home/niko/work/kinto-admin/node_modules/react-transform-hmr/lib/index.js:51
throw new Error('locals[0] does not appear to be a `module` object with Hot Module ' + 'replacement API enabled. You should disable react-transform-hmr in ' + 'production by using `env` section in Babel configuration. See the ' + 'example in README: https://github.com/gaearon/react-transform-hmr');
^
Error: locals[0] does not appear to be a `module` object with Hot Module replacement API enabled. You should disable react-transform-hmr in production by using `env` section in Babel configuration. See the example in README: https://github.com/gaearon/react-transform-hmr
at proxyReactComponents (/home/niko/work/kinto-admin/node_modules/react-transform-hmr/lib/index.js:51:11)
at Object.<anonymous> (/home/niko/work/kinto-admin/node_modules/react-jsonschema-form/lib/components/fields/ArrayField.js:39:59)
at Module._compile (module.js:435:26)
at Module._extensions..js (module.js:442:10)
at Object.require.extensions.(anonymous function) [as .js] (/home/niko/work/kinto-admin/node_modules/babel/node_modules/babel-core/lib/api/register/node.js:214:7)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/home/niko/work/kinto-admin/node_modules/react-jsonschema-form/lib/components/fields/SchemaField.js:13:19)
at Module._compile (module.js:435:26)
at Module._extensions..js (module.js:442:10)
at Object.require.extensions.(anonymous function) [as .js] (/home/niko/work/kinto-admin/node_modules/babel/node_modules/babel-core/lib/api/register/node.js:214:7)
Sample references in published lib files:
When a form field displays an error, it's in a li
tag, which isn't in an ul
tag.
li
that are in a div
without a ul
A li
item should be in a ul
tag.
The li
tags aren't in a ul
tag.
0.19.2
Spec: http://json-schema.org/latest/json-schema-core.html#anchor25
I suggest we start by supporting local definitions only:
{
"definitions": {
"address": {
"type": "object",
"properties": {
"street_address": { "type": "string" },
"city": { "type": "string" },
"state": { "type": "string" }
},
"required": ["street_address", "city", "state"]
}
},
"type": "object",
"properties": {
"billing_address": { "$ref": "#/definitions/address" },
"shipping_address": { "$ref": "#/definitions/address" }
}
}
(Sample JSONSchema source extracted from http://spacetelescope.github.io/understanding-json-schema/structuring.html)
When I have an enum without a default value it looks like the first one is selected, but actually I have to change it to another and the first one again so it's set.
The first item in the select box should be something like "please select" then.
Should we use this? The look and fill could improve a lot, but at the same time I wonder if that's really what this library should do.
https://github.com/callemall/material-ui
Thoughts?
Nice to have: it would be more maintainable to have tests split per widget.
We only care about dist files for packaging, so they're available through npmcdn. Hence they should be ignored from git versioning.
Reference discussion: #44 (comment)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.