Open gregor opened 3 weeks ago
Thank you for your question. I believe this was done this way for historical reasons, and also because this is how json-server works internally (it simply attributes an id to the record and returns it along with the data from the request).
Now, we could imagine changing the return value to include the response json
, but only if this solves an actual issue.
Granted this dataProvider is designed to work with json-server, the current implementation should cause no issue.
Can you elaborate on what made you ask this question, and what issue did you face (if any)? Thanks
We use react-admin
as our backoffice tool. We are a parcel storage solution. When creating certain new record types (especially deliveries or returns), we have backend logic in place that not only creates a unique ID for the record but also assigns an incremental number unique to the physical location where the parcel was accepted. We use this as a simple warehousing tool to quickly locate physical packages. Since we need to ensure that the assigned number is unique, this step is done by the backend logic. It is added to the other record data passed to the create endpoint by the backoffice (or our smartphone app). The number is then manually written onto shipments. For this, we show it in our react-admin
implementation in a dialog on create success. If the data server discards the server response containing the full record data and returns the sent data instead, it workarounds to access the value are needed.
Makes sense, thanks for the feedback. I'm marking this as an enhancement request, feel free to open a PR against the next
branch.
https://github.com/marmelab/react-admin/blob/45151e0b844a83dc8309a56ad9ca8ea355ce3aee/packages/ra-data-json-server/src/index.ts#L154
What is the reasoning for this line? Any server-side logic to the data is ignored and cannot be accounted for as part of the response.
I would expect this to be:
data: { ...json },
ordata: { ...params.data, ...json } as any,