Form fn on update form data

[nzambello]

@giuliaghisini added a callback for the Form component to handle form state updates.

[tiberiuichim]

@nzambello I like the added method, though I'd be very interested also in your thoughts on #1711

With it, you can have a component get the whole form state with:

const [contextData, setContextData] = useFormStateContex();
const {formData} = contextData;

This way you also don't have to customize Edit.jsx to inject onChangeFormData.

[nzambello]

IMO these are two different things.
This PR gives two aspects:

• fix click events within the form
• give the parent of the form direct access to changes events and data, useful if we have multiple forms

[nzambello]

@tiberiuichim if we merge #1711 we should update this or the other way around.
Maybe I'm wrong on the second point of my previous comment, what do you think about?

[tiberiuichim]

@nzambello no, the points you raise are absolutely valid.

I'm fine with restructuring my PR after this one is merged

[tiberiuichim]

I've been exploring the form implementation, it seems it's a hot topic in our little community.

I have had a concern about the performance side of things. I've noticed slowdowns with volto-slate when dealing with large text pages. I've optimized some stuff there, I've also tested and it seems the slowdown is only seen in development mode, with a production built bundle I couldn't see it. But I'll quote the React docs:

We do not recommend doing deep equality checks or using JSON.stringify() in shouldComponentUpdate(). It is very inefficient and will harm performance.

In this PR we're doing it on each form update (which happens after every single click or key entered). For what is worth, lodash isEqual is not better, I've tested here: https://www.measurethat.net/Benchmarks/ShowResult/126840

In any case, that comparison is optional, so it would concern only those who pass the onChangeFormData param.

[tiberiuichim]

> {a: 1} !== {a: 1}
true

[tiberiuichim]

pmndrs/jotai#23 (comment)

[tiberiuichim]

@nzambello you might be interested in our work in https://github.com/eea/volto-blocks-form

It splits the form in multiple reusable components, I've also integrated your idea of onChangeFormData, but I made it easier by not having a state in the form. The form now works as a controlled input, which makes it easy to embed a form in a form.

See how easy it is to use it.

[tiberiuichim]

We've started treating forms as "controlled inputs", having subforms without a state, for example in volto-columns-block. We model the form API after this component. Would it make sense to rename 'onChangeFormData' to 'onChange', to mimic the Field API? @plone/volto-team