Just to chime in. I use a custom form because I have a particular use case.
- With one of my choice components, I need to write both the visible description of the choice, as well and the underlying number. So in my example below, I need to save both the Lesson Length Name as well as the rate that’s associated with that Lesson Length. For me lesson rates can change in the future, so to avoid affecting older lessons when rates change, I can’t use relations to pull in a rate based on length.
- I use that underlying number as part of a live calculation. This is so the user can verify in real time if everything is correct before clicking on submit. Each user can have different rates, and rates can differ per user, so everything needs to be dynamic.
In some cases, I also allow the user to enter a custom rate.
So in my case, a custom form is the only viable option, since I can’t achieve the same functionality with a native form. It also allows for some more robust validation before allowing the user to submit a form.
Fortunately for me, this app has about 1.5 users, so going over usage limits is not a big concern, but I understand where it can be something to consider. There are use cases for custom forms, but if they can be avoided, I do agree that a native form is the way to go.