Is there a reason we have `checkOperation` as a se...
# contributing-to-airbyte
j
Is there a reason we have
checkOperation
as a separate endpoint instead of performing validation of the
OperatorConfiguration
internally in `createOperation`/`updateOperation`?
u
As far as I can tell this level of check happens internally for all other resources. Endpoints like
checkConnection
are different because they are performing a much more heavyweight operation and are actually interfacing with an external resource.
j
The current implementation seems to imply that
checkOperation
is doing something similar. It doesn’t now, but are there plans to?
u
If not, I’m going to remove
checkOperation
and move the validation to happen internally to `createOperation`/`updateOperation` .
u
will try to speak for chris since he's out.
u
i think the idea is that we want to allow the user to validate an operation before it gets committed.
u
the way this presents to the user is that they get feedback in the UI on whether the operation they've configured makes sense when they set it up (but before they hit save on the whole connection).
u
then from the UI's point of view setting up the connection (and its corresponding operations) all happens at once.
j
i don't think we have to keep it that way. but i think that's how we ended up here.
u
Charles is totally right. We have separate endpoint due to the fact how we manage form - as we create all resources at once as form is submitted, to have better UX we validate subresources ( operations ) when we finish some step. Otherwise we have to have more complex flow, opening other popups/modals and displaying errors.