Still allow generic Errors in redwood forms

[orta]

The form error property accepts any:

interface FormProps extends Omit<React.ComponentPropsWithRef<'form'>, 'onSubmit'> {
    error?: any;

But raises an exception if it doesn't conform to RWGqlError which is an internal type. The form does a validation check for the other possible property networkError (via the null check) but doesn't for graphQLErrors. This was the minimal case change, but I think a tighter change might be making:

interface RWGqlError {
  message: string
  graphQLErrors: ReadonlyArray<GraphQLError>
  networkError: Error | ServerParseError | ServerError | null
}

to

interface RWGqlError extends Error {
  graphQLErrors?: ReadonlyArray<GraphQLError>
  networkError?: Error | ServerParseError | ServerError | null
}

[Tobbe]

I'm getting the same cypress e2e error on my PR as you're getting here. I've been trying to figure out why, but no luck yet :(

[jtoar]

@Tobbe See my comment here: #3772 (comment).

[Tobbe]

The tests all pass now with the new version of cross-undici-fetch ✅

As far as this PR goes I like it 👍
But also wouldn't mind the proposed change to make it extend Error

@dthyresson You have also looked at the gql error stuff before. What's your take?

[dthyresson]

Thanks @orta for this PR.

FYI @dac09 and I recently spoke to the Guild about different approaches to error handling -- as the client side relies a little too much on Apollo's way of using error codes and having errors outside the data block.

Instead, they promote a way of including errors as part of the SDL and using union types so that error message and info comes back as part of the data.

See: https://blog.logrocket.com/handling-graphql-errors-like-a-champ-with-unions-and-interfaces/

But, we'll revisit this concept in V2.

[dthyresson]

Thanks again @orta

[orta]

Yeah, I'm an "Errors in unions" person myself - https://artsy.github.io/blog/2018/10/19/where-art-thou-my-error/