AutoField API Proposal

[mariusrak]

Hi, I like the idea of changing fields components by context. Could we push it little further and do this?

import { AutoForm } from 'uniforms'
import { CustomAuto } from './custom-autofield-as-described-in-docs'

<AutoForm.AutoFieldsOverrider autoField={CustomAuto} />
  <AutoForm ... />
</AutoForm.AutoFieldsOverrider >

const AutoForm.AutoFieldsOverrider = ({autoField, ...props}) => <AutoForm.AutoFieldsContext.Provider value={autoField} {...props} />

And AutoForm and AutoFields would then check the AutoForm.AutoFieldsContext to see which AutoField should be rendered.

Also AiutoFields is currently tied to styled package. But it is not neccessary since it is basically only a loop. Or whatever it is, it is not style-related.

[radekmie]

Hi @mariusrak. Moving AutoField out of the theme packages is generally a good idea (and actually one I already had written down, yet not on GitHub). Doing the same with AutoFields is slightly different, as right now, it always renders an additional div. I guess we won't break anyone's project by not doing that (i.e., rendering React.Fragment instead), but we may.

I do agree that we should do that in v4, together with #980, #1114, and #1126.

[wadamek65]

We've revisited this issue and came to the conclusion that hoisting AutoField to the core package will not be very practical so we've decided against it. Each theme will define its own one as it currently is.

We will however change the behavior of the AutoField to no longer render a wrapper and instead, a React.Fragment.

[mariusrak]

Why wouldn't it be practical? I think it's more than practical - it's logical, as it is not related to style in any way. But, anyways, my original proposal is not about AutoField but more about more simple way to override AutoField

[wadamek65]

@mariusrak In terms of overriding AutoField through a context like you suggested is already possible via the componentDetectorContext.

As for hoisting the AutoField/s - while we agree from a logical standpoint it makes sense as it by itself is in theory theme-agnostic, the fields it renders aren't. We haven't found a way to move it to the core package without the theme packages having to do additional work in terms of specifying which components should be rendered. In the end, it would be a trade-off because there would be additional usage setup required (as in for example rendering an additional context at the top of the tree). This is why we decided to keep it the current way as we think the change would make things slightly more complicated. If you do have a specific implementation/solution in mind though we would love to see an example of it!