Improve documentatoin of linked inputs with FormDataConsumer

[mithoska]

I am trying to link together 2 input fields with FormDataConsumer and ReferenceArrayInput/SelectArrayInput.

My code looks like this:

                <ReferenceInput label="Tipus" source="type" reference="categories" validate={ required() } >
                    <AutocompleteInput optionText="name" />
                </ReferenceInput>
                <FormDataConsumer>
                    {({formData, ...rest}) => {
                        console.log(formData)
                        if ( formData.type !== undefined ) {
                            var t = formData.type;
                            var myType = t.toString();
                            var myOptionText = `${myType}.name`
                        }
                        return (
                                    <ReferenceArrayInput label="Categories dynamic" source={myType} reference="categories" {...rest}>
                                        <SelectArrayInput optionText="name" />
                                    </ReferenceArrayInput>
                        )
                       }}
                </FormDataConsumer>

I used the Howto on your site (https://marmelab.com/react-admin/Inputs.html#linking-two-inputs) and of course Stackoverflow with all my questions I had.

I still miss something from the documentation, and if possible that would be great if it would be there.

Your example shows this for FormDataConsumer:

        <FormDataConsumer>
            {({ formData, ...rest }) =>
                 <SelectInput
                     source="city"
                     choices={getCitiesFor(formData.country)}
                     {...rest}
                 />
            }
        </FormDataConsumer>

You are using a getCitiesFor function here which filters/collects/reaches out to another API endpoint/whatever - which is not visible.

I'd like to be more than happy if the getCitiesFor function would be in the examples as well, so we know how it is being used.

Would it be possible to provide that data?

[RafeSacks]

I agree, though the docs are quite good already, a little more context would have helped a lot.

This took some playing with for me as well, mostly to figure out what I had to protect against and when to expect components to update (but then again I am pretty new to React). I was overcomplicating it at first. It is just a form-level input change event. Maybe that should have been obvious but at first I was working to understand how it links components (it does not, technically, it just allows an indirect data dependency, right?)

The pattern I've been using is to pull the member I want from formData, test if it is valid or default it, etc, and then pass that as a prop. The child component seems to only render when the value changes (FormDataConsumer runs when anything in the form changes so this was important to me; to only update when what I want to hook in to changes). React seems to handle all of this for us quite well (props driving updates).

I am far from an advanced user here though so please read in that context.

[fzaninotto]

This request enters the gray area between pure documentation and recipes for a particular use case. I believe all the documentation necessary to achieve what you describe is already there (including <Query>).

I'm leaving this one open but I personally think that the answer belongs to StackOverflow.

[hithacker]

What is getCitiesFor doing? Can it actually be making an API call?

[Mohit-pratap]

HI, I am new to react-admin and also in ReactJs. I am stuck with a custom button. What I want to do is I have a user list when I click on the row it goes to the user edit page there I have a custom button and I want to edit some values and send it to the server. But in custom button I am using useUpdate and in custome button I am not able to get the form data which I edited. Please help

[djhi]

Hi @Mohit-pratap,

Please use StackOverflow with the react-admin tag for this kind of questions

[zachrybaker]

I believe all the documentation necessary to achieve what you describe is already there (including <Query>).

For seasoned uses, I believe you are right. But if you are fairly fresh react-admin or relatively young on react patterns and principals you are going to have a tough time deriving the undocumented pattern from the (sometimes stale) documentation and the mental model you are supposed to combine from consuming the rest of the documentation.

So since its a 'grey area', why not fill the gap?