Add Weakguard to decoders library about decoders

[nvie]

Yeah, great idea! It will need some good documentation, and configurability, so it may take a bit to do it well. This is an area where you can shoot yourself in the foot.

---

I'm thinking of extending the current Guard API so you can provide an optional callback (called whenever a guard would throw an error), which would allow you to both log/inspect, and handle the error in your preferred way, and opt-in to continuing or keep-failing.

const verify: Guard<Something> = guard(myDecoder, { onError: myCustomCallback });

Since all projects have different preferences, I don't think I can make it more specific than this generic callback structure.

The callback would receive:

• error: Error - The Decoding Error instance (whatever error the guard throws today, literally)
• originalBlob: mixed - The original blob value that failed to decode, for further inspection, or logging, or modification

It would have to return:

• An explicit fallback value (of type T)

---

You could then use it to build your own project-specific "weak guard":

function weakGuard<T>(decoder: Decoder<T>): Guard<T> {
  return guard(decoder, {
    onError: (error: Error, originalBlob: mixed): T => {
      if (process.env.NODE_ENV === 'production') {
        // Report the error to Sentry
        sentry.withScope((scope) => {
          scope.setExtra('blob', originalBlob);
          sentry.captureException(error);
        });

        // But let's allow unexpected inputs through, sacrificing correctness
        // $FlowFixMe - deliberate force-cast here
        return ((originalBlob: any): T);
      } else {
        // Keep failing in development mode
        throw error;
      }
    },
  });
}

---

All of the logic inside of the onError handler is inherently project-specific though. But I could provide this snippet as a good example for how to build something like this.

[sfarthin]

That looks great 💯

[github-actions]

We have detected this issue has not had any activity during the last 60 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better collaboration environment for all. Thank you for your continued involvement and contributions!