[WIP] fix: utilize 'error-causes' to create errors for 'signIn' and 'signUp' SDK functions

[oliver-day]

Description

• Addresses Issue #49

Questions

1. Should I add error-causes to greenruhm-web and have all possible errors generated during sign up with error-causes (If so should we come up with a convention for error codes)?
2. Should a 500 response from the greenruhm-web api be handled with this implementation?

NOTE: I have included an UserRejectedConsentToShareEmail error so that all errors generated in the existing sign in and sign up flows are created with error-causes. In an upcoming PR, we will move away from using magic.connect.requestUserInfo() and this error will no longer be necessary so it can be removed at that point in time.

TODO

• Update sign in and sign up error message based on changes with respect to https://github.com/Greenruhm/greenruhm-web/pull/692

[ericelliott]

Should I add error-causes to greenruhm-web and have all possible errors generated during sign up with error-causes (If so should we come up with a convention for error codes)?

You mean, first create errors with named causes in Greenruhm Web so that you can translate them to caused errors here based on the responses from Greenruhm Web? If it saves you time on rework, why not?

Should a 500 response from the greenruhm-web api be handled with this implementation?

You should be able to handle that with the default error response. Error causes has an unexpected error case built-in:

const UnexpectedError = {
  name: "UnexpectedError",
  message: "An unexpected error was thrown",
};

[oliver-day]

It looks like we removed the error handling logic for Magic errors - I assume we're moving that error logic elsewhere. Is this correct? Where did it move to?

Within src/features/user/sign-up.js and src/features/user/sign-in.js

[ericelliott]

won't I need to merge the named signUpErrors I created in this https://github.com/Greenruhm/connect/pull/52 into the main branch of connect before I will be able to reference them in greenruhm-web?

Yes.

If so the path forward would be:

1. Merge the errors you need to display in connect so that you can import them into Greenruhm-web.

Those are the ones with http status codes like 400 and 500.

One step at a time.

[oliver-day]

Closing this PR as I have made an updated one with the fix/sdk-functions-error-handling-1 branch. This was done to avoid having to resolve merge conflicts as a result of later work where connect was updated to use CJS modules and additional changes to named error causes.