Consider inverting theme structure

[alexkreidler]

Currently, users must choose between uniforms-<style> packages.

As implemented, most of the logical components simply calls parent classes. The only differences are really in the display/field components.

If you were to move all the display components into a big map of their names, then that object could be passed into each type of Form instance. This would allow users to

1. implement form themes with their own component libraries
2. use a different theme for different forms a little more easily

No. 1 is the most important for me personally. I would have to copy and maintain a whole separate package with a lot of boilerplate to implement the forms I want to.

But with this change, I would implement the <Type>Field components from the autofield algorithm, pass those in an object like:

interface FormTheme = {
    RadioField: React.FC<Props>
    DateField: ....
}

then I could use autoform like

const myTheme: FormTheme = //impl
<AutoForm schema={schema} onSubmit={console.log} theme={myTheme} />

And users could simply import the appropriate already-implemented ones like

import bootstrapTheme from "uniforms-bootstrap4"
<AutoForm schema={schema} onSubmit={console.log} theme={bootstrapTheme} />

This would definitely be a breaking change and you'd have to change the default export of those different theme packages, but it might be worthwhile.

Let me know what you think!

[radekmie]

Hi @alexkreidler. First of all, a static component map would not work, as most apps require custom field components for the same types, e.g. NestField can render an address form correctly, but a custom AddressField may have a different layout. Anyway, this and a few other arguments, as well as the approach I'm working on, are in #640.