react-admin icon indicating copy to clipboard operation
react-admin copied to clipboard

Implement `parse` prop for Edit/Create

Open SleepWalker opened this issue 4 years ago • 1 comments

Is your feature request related to a problem? Please describe.

Currently, thanks to react-final-form we have a way to change the format of the separate field by using parse/format props. However in some cases you need to perform parse/format on the entire Record level.

We have a prop transform that allows us to change the Record before sending it to dataProvider, but we do not have a corresponding prop to convert data from dataProvider into a correct Record format.

An example:

In order to use <TranslatableInputs /> you need to have fields in format { [locale: string]: string } and there is no way to use different format.

It seems that it not an easy task to allow parse/format on the TranslatableInputs level, because it requires rich data structure that may also be dependent on other record fields. Moreover TranslatableInputs actually does not know which fileds will be rendered.

Describe the solution you'd like

In order to allow parse prop, we need add also a new prop for a dataProvider hooks (e.g. useGetOne):

    const { data: record, loading, loaded } = useGetOne<RecordType>(
        resource,
        id,
        {
            action: CRUD_GET_ONE,
            onFailure: () => {
                // ...
            },
            // something like this
            parseResponse: (resp) => resp,
        }
    );

Describe alternatives you've considered

Currently the only way to provide correct Record for Edit/Create is to implement data transformation logic inside DataProvider. The transform prop without it's counterpart parse prop has really limited use.

SleepWalker avatar Apr 02 '21 08:04 SleepWalker

@djhi I think that DataProvider is an adapter for CRUD operations on some source of data. It should not be responsible to provide a data in format that is required for a particular field in some form view.

Data requirements for TranslatableInputs and the fact that that field is actually used somewhere is implementation details of the form, that implements that particular use case. For example I don't need that data format applied for the List view (or in reference field). It is required only on Edit page and only for edited Record, because without data transformation it's not possible to use form fields.

Of course you can put all the application logic, including the React components and css inside the dataProvider but it's just not right. This is the reason why we have the transform prop (and parse/format props on fields) which allows us transform the data received from Form into the Backend format. And now I propose to also add a way for such transformation in other direction Backend -> Form


One more example. I've have overridden the GET_ONE method in my dataProvider to create additional i18n field that can be used with TranslatableInputs. But the result of my transformation is erased by GET_LIST request, because on the same page I have a ReferenceInput to populate AutocompleteInput for the same resource. So now I must also implement that hack with extra field for GET_LIST request :facepalm:. It's totally weird.

SleepWalker avatar Apr 02 '21 09:04 SleepWalker

This proposal hasn't received any attention from the community for quite some time, and we won't implement it in the near future. So I'm closing the issue. Feel free to contribute a PR implementing this feature, we'll look at it carefully.

fzaninotto avatar Aug 01 '23 14:08 fzaninotto