Add support for themes

[n1k0]

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.

[almet]

Putting this here since I was thinking about it: since most of the theming will be done using html, should we have our default components load their templates from an external file instead, which could be looked up at different locations ? As such theme authors would just need to specify a set of files which would contain only JSX.

The approach you're proposing seems more powerful, but also introduces a bit more complexity. If theme authors are able to cope with it, then doing this is probably a good idea.

[n1k0]

should we have our default components load their templates from an external file instead

What format would use this external template file, jsx? How would we load/parse it? How would it look? Could you write a quick example?

[zbyte64]

I found the current SchemaField connection to not be enough for bootstrap integration. Here is a gist of what I currently have for bootstrap theming SchemaField: https://gist.github.com/zbyte64/67a06857d236e42e852d

The issue I am seeing is that the FieldComponent does not accept className and bootstrap wants inputs to have form-control class name.

[almet]

So, I've spent some time read things that already exist in this area. React-Template is one, but I'm not a big fan of having control structures directly in the XML tags.

My thinking was coming directly from the python world, where we would have templates like this (jinja2 syntax):

{% if variable == "test"%}
<Component>
// more jsx here
</Component>
{% endif %}

And in the components you would just pass the attributes to be used:

return render("template_name", attributes);

One equivalent in JS seems to be defined by this solution

[n1k0]

@zbyte64

The issue I am seeing is that the FieldComponent does not accept className and bootstrap wants inputs to have form-control class name.

Interesting, that's a good use case for ui:widget options so we could pass classNames to the widget as well:

{
  "foo": {
    "ui:widget": {
      "name": "updown",
      "classNames": "foo-class"
    }
  }
}

But for bootstrap it needs more than just classNames here and there, it also has high expectations on specific tags nesting :/

[n1k0]

@almet Using external pure-JSX templates seems odd to me, and these could easily just be simple functional components if you ask me (basically what's my suggestion above is). As for the python-like string-based template engine, I don't feel it, like, at all (react users using a react lib are likely to expect to use react syntax to achieve things) :)

[magopian]

After some discussion with @n1k0, we found out that this was a very ambitious project, and (maybe?) out of scope for this lib.

At the same time, we do acknowledge that there's a need for: 1/ a better styling by default 2/ the possibility to customize the theme

To answer 1/, we're going to choose a css framework that we'll use by default. See #99

To answer 2/, we need to add a clear statement in the documentation that we're not going to support theming, and then link to the customization API documentation, explaining how to apply different styles. See #98