rjsf-team/react-jsonschema-form

A React component for building Web forms from JSON Schema.

react-jsonschema-form's Issues

react-transform-hmr is referenced in lib files

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:

Suport for sub-forms

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?

Enums don't require a type definition

(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"]
},

Option to specify boolean labels?

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.

Add links to fields in error in the Error section at the top of the form

This should be trivial as we have unique ids for each widget.

Document that we don't support theming

Link to the customization API documentation, explaining that it could be used to achieve some of the needs for theming.

Add support for custom widget components

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}
}

Render without form tag?

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.

Add support for JSONSchema type "integer"

http://json-schema.org/latest/json-schema-core.html#anchor8

Playground doesn't render CodeMirror syntax styles

JSON code should be highlighted.

Add support for themes

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.

Cannot enter decimal value for number type

Steps to reproduce:

1. Navigate to "Numbers" tab in live demo
2. Select and backspace Number field to clear it
3. Once reset to 0, attempt to enter "3.14"
4. Note that it is not possible

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

Support custom object and array fields through `ui:widget`

Reference discussion: #44 (comment)

Error LIs should be in a UL

Prerequisites

• I have read the documentation.

Description

When a form field displays an error, it's in a li tag, which isn't in an ul tag.

Steps to Reproduce

1. Go to http://mozilla-services.github.io/react-jsonschema-form/ on the "errors" tab
2. check the errors (for example on the "first name" field)
3. see that there's li that are in a div without a ul

Expected behavior

A li item should be in a ul tag.

Actual behavior

The li tags aren't in a ul tag.

Version

0.19.2

Issue when running npm install: missing history

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.

Use material-ui for the generated forms

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?

unmet dependencies

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

• [email protected]
• [email protected]
• [email protected]
• [email protected]

Allow setting formData after the Form component is mounted

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.

Handle fixed items arrays

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.

Performance optimizations

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.

Add PasswordWidget

Add support for custom field class attribute to uiSchema

const uiSchema = {
  foo: {
    classNames: "a b c d"
  }
}

Validation doesn't work for enum fields

It seems to actually use the index rather than the text.

Option to hide a field?

Is there an option we can pass to the ui schema that would result in a field being hidden?

Cannot resolve module 'buffertools'

$ 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

Required array and object fields are not denoted in their fieldset caption

Use the first enum item value as the field state default

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.

Custom CSS class names does not work

https://github.com/mozilla-services/react-jsonschema-form#custom-css-class-names

Per-field error contextualization

Right now validation errors are listed on top of the form, while we should obviously render them contextually at the field level.

Object (and array ?) fields : classNames on the fieldset

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 ?

Add computed fields ?

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.

Allow registering custom widgets

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

Enums have to be changed to be applied

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.

Support enumNames for enums

We should probably offer support for enumNames, which is draft v5 atm:

"obj": {
  "enum": [{a: 1}, {b: 1}, {c: 1}],
  "enumNames": ["a", "b", "c"]
}

Avoid reformatting entered JSON in the playground

This "feature" makes it really hard to tweak the JSON data in the editors.

Custom validator

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:)

Improve styling of errors by default

Default field label should be its parent object key property

{
  type: "object",
  properties: {
    firstName: {type: "string"}
  }
}

The firstName field should have its label automatically set to firstName by default.

Add a unique ID to widget props

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?

Split tests to be per widget

Nice to have: it would be more maintainable to have tests split per widget.

Multiple buttons

It would be great to be able to use multiple buttons in the form. Maybe we could pass them via children ?

Add support for canonical and inline referencing

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)

Add support for "multiple" select

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) )

Support for joined schemas with `anyOf`, `allOf`, etc?

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?

Upgrade to Babel 6

A required boolean, a checkbox and validation

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.

Object without `properties` throws

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.

What range DatePicker can be used with the plugin?

Can you provide a suggestion on what DatePicker that supports range select can be used with the plugin?

New property to override default submit button text

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.

Avoid versionning dist files in git

We only care about dist files for packaging, so they're available through npmcdn. Hence they should be ignored from git versioning.