useForm and derivatives need a clear distinction between props to be send to the server and form props

[vinclou]

The Problem:

1. Workarounds around this limitation blur one's programmer intention and make code less clear in terms of type safety and just adding code bloat.
2. Question the use of utility hooks offered by Refine since u end up using 10% - 30% of the intended func.
3. Makes the utility library less flexible

Proposal:

Because FormProps is the same as the useMutation it causes lots of hassle, very often I face a situation where I can not precisely map form values to what gets sent to the server, or for some reason don't want to or need to process updates in a particular way, before the submission.

If as a user I can do something like this:

And if I don't want to the default is mapped to subscription updates(it might not work out with TS)

const exp = useForm<Subscription, HttpError, SubscriptionUpdates, IFormSubscriptionUpdates>({...Props})

Then essentially I wouldn't need to use extra hooks, overrides, or other workarounds you could possible come up with to
deal with form values being different from server-sent props.

Let's start with an example.

/**
* @description One of the possible workarounds to deal with type differences
*  In the example below date needs to be converted to API format.
* The ideal solution would be just to convert it with onFinish or onChange events and use the mutation returned by
* useForm hook, but in this situation, TS won't let you do it and complain.
*
* There are plenty of workarounds, so don't focus on bad code =) 
*/
function EditSubscriptionForm({ subscriptionId, termEnd }: { subscriptionId: string; termEnd: TPossibleVal<number> }) {
	const { formProps: editFormProps } = useForm<Subscription, HttpError, IFormSubscriptionUpdates>({
		action: 'edit',
		resource: `accounts/Internal/v1/Subscriptions/${subscriptionId}`,
		redirect: false,
		invalidates: ['all'],
		queryOptions: {
			enabled: false
		}
	})       
	const { mutate: editSubscription } = useUpdate<Subscription, HttpError, SubscriptionUpdates>()
	const termEndDateObj = termEnd ? CalendarDate.fromApiFormat(termEnd).toDate() : new Date()

	const handleFormUpdates = (values: IFormSubscriptionUpdates) => {
		const { currentTermEnd, quantity } = values

		if (!currentTermEnd && !quantity) {
			message.error('Please enter a new term end date or quantity, to submit a form')
			return
		}

		const subUpdates: SubscriptionUpdates = {
			...(quantity && quantity !== 0 && { quantity: quantity })
		}

		if (currentTermEnd) {
			const newTermEnd = convertToApiDate(currentTermEnd)
			subUpdates.currentTermEnd = newTermEnd
		}

		editSubscription({
			resource: `accounts/Internal/v1/Subscriptions`,
			id: subscriptionId,
			values: subUpdates,
			invalidates: ['all']
		})
	}
	return (
		<div className=''>
			<Form<IFormSubscriptionUpdates> {...editFormProps} onFinish={handleFormUpdates}>
				<Form.Item className='w-full' name='quantity' label='Quantity' initialValue={1}>
					<InputNumber min={0} max={999} />
				</Form.Item>
				<Form.Item className='w-full' name='currentTermEnd' label='Term End' initialValue={dayjs(termEndDateObj)}>
					<DatePicker
						allowClear
						id='end date picker'
						disabledDate={current => {
							const start = dayjs()
							return current < dayjs(start) || current > dayjs(termEndDateObj)
						}}
					/>
				</Form.Item>
				<Button type='primary' htmlType='submit'>
					Submit
				</Button>
			</Form>
		</div>
	)
}

[omeraplak]

Hey @vinclou ,
Good point, this was a problem I faced from time to time. Do you want to create a PR?

[MetaMmodern]

Okay, I see. Then we're dealing with different types of issues here. You have different endpoints for the same resource. I have different scemas/interfaces for the same resource when getting and editing the resource. Althought your issue kinda includes my issue.
We'll see what will refine core team come up with :)

[vinclou]

@MetaMmodern Well it's not an easy feature in terms of all different parts of refine pkgs to update, starting from the core lib, updating type signatures is relatively straightforward(your use case), my proposed feature requires whole lotta testing + making sure it's non-breaking, t.e if mutationRoute is not present the things get defaulted to the resource route instead.

It is a medium-risk feature, but probably the core Refine team should investigate how popular is this use case; I would argue
it adds lotta flexibility anyway and removes the boiler plate too. Since when you declare your won mutation it is essentially code
duplication, since there's a mutation declared under the hood, you are just forced to decline to use it.

[vinclou]

@omeraplak But I do think this will make ur framework more flexible and users would write less boilerplate code without the custom mutation hooks that currently need to be declared.

I'll probably write up a discussion with my Feedback on Refine and address the good and bad things it might help you plan for this year's roadmap.

[aliemir]

Hey @MetaMmodern and @vinclou, we've released our roadmap for refine v4 and posted a RFC here #3527 We'd love to hear your comments and feedbacks about it. (Not mentioned in the roadmap but we will work on this discussion too)

[vinclou]

@aliemir Thanks, will take a look over it!