[RFC] Simplify ObjectField and ArrayField APIs

[FermiDirak]

Summary

From using Formula-one, I made two observations:

1. ObjectField feels unnecessary when you using them solely for the purpose of reaching into an object. It has useful props such as validation, but when I'm not using these props it feels unnecessarily cumbersome to include it in my form JSX tree.

2. link can be unintuitive (especially in formula-components) and it's hard to follow what link refers to in a given context

A change I would like to suggest is that ObjectField and ArrayField are removed in favor of accessing nested properties directly.

Basic Example

<Form ...>
  ({formData, onSubmit} => (
    ...
    <Field link={formData.name.firstName} />
    <Field link={formData.name.lastName} />
    ...
  ))
</Form>

Motivation

This change would reduce excessive JSX nesting and make tracing the context of a link more transparent and straight forward.

Naturally, interfaces from ObjectField and ArrayField (validation, {and/remove/move Field}) are incredibly useful and could be stripped into their own respective components.

<ObjectField validation> => <Validate validation> <ArrayField>{(links, {add/remove/moveField}) => ... => <List>{({add/remove/moveField}) => ...

Another Example

This is how I envision consumption of Formula-One could look like: https://gist.github.com/FermiDirak/f6e39ba8bb9cb88781c7c7c18ec2f1ea

Drawbacks

• I understand that ObjectField and ArrayField provide type validation. With this change, the way type validation is done would need to be rethought (possibly? not sure).
• This change would not be backwards compatible

I'd love to hear feedback. I think these changes could help adoption rates and help increase maintainability of projects using Formula-One.

[zgotsch]

From an API perspective, I like this. Unfortunately, one of the top design goals of F1 was to allow us to have full flowtype coverage of the form fields. This is what initially drove the current design (ObjectField and ArrayField map to $ObjMap and $Call respectively). I would be interested in exploring new APIs, but without some very complex (and probably non-userspace) flow stuff (like idx uses), our power to design the API is limited.