The idea of form_data vs. values is to store whatever the user's browser sent in form_data and only convert it on demand to values. form_data is always* dict[str, str] whereas values can be dict[str, str | int | list[str] | dict[str, str]] or even more types.
Currently SchemaFormInput is responsible for understanding the values type of its value (eg. DateTimeField: ISO 8601 string #438, NumberField: number etc.) and making whatever conversion is required to enable an <input> to display it.
Should this conversion be pushed to the backend, or should we expose the raw Response.form_data so that field implementation would be more straightforward <input type={type} value={value}>?
The form_data -> values -> form_data conversion cycle may still be preferred in order to perform satanization.
*) Actually not true due to FileUploadField value in form_data always being list[str] regardless of number of files. So we are already touching the form_data in frontend before it reaches the databae.
The idea of
form_datavs.valuesis to store whatever the user's browser sent inform_dataand only convert it on demand tovalues.form_datais always*dict[str, str]whereasvaluescan bedict[str, str | int | list[str] | dict[str, str]]or even more types.Currently
SchemaFormInputis responsible for understanding thevaluestype of its value (eg.DateTimeField: ISO 8601 string #438,NumberField:numberetc.) and making whatever conversion is required to enable an<input>to display it.Should this conversion be pushed to the backend, or should we expose the raw
Response.form_dataso that field implementation would be more straightforward<input type={type} value={value}>?The
form_data -> values -> form_dataconversion cycle may still be preferred in order to perform satanization.*) Actually not true due to
FileUploadFieldvalue inform_dataalways beinglist[str]regardless of number of files. So we are already touching theform_datain frontend before it reaches the databae.