introduce simple user provided caches for parse/validate

[yaacovCR]

BREAKING CHANGE: parse/validate become potentially async when provided with a cache with an async getter,

Introduces parseSync/validateSync to throw when an async value is returned.

Updates all non-cache tests to use parseSync/validateSync.

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	e07ed7a
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/672a00ace20de60008db1420
😎 Deploy Preview	https://deploy-preview-4285--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

[yaacovCR]

Merging this would take care of #3241.

This PR includes within it #4278 => a type-only fix for #3241.

[JoviDeCroock]

I personally don't think an opinion like this fits the reference implementation, the inputs to the cache also suffer from a lot of short-comings. For one a lot of caches would require contextual input, i.e. does this user even have access to this part of the schema which informs how the cache key looks.

I would prefer us altering the signature as suggested in the issue and discuss this on existing PR's rather than superseding them verbatim 😅

[yaacovCR]

I personally don't think an opinion like this fits the reference implementation,

This seems to be a separate bit of feedback, so I think it makes sense to address it directly. I agree that it's debatable as to whether a caching system need be provided within the reference implementation vs user land. I think it's reasonable to bring it into the reference implementation, with the plus-side in that it allows for caching without advanced plugin frameworks. A negative would be the potential maintenance burden. I think the balance between these is pretty neutral in this case.

the inputs to the cache also suffer from a lot of short-comings. For one a lot of caches would require contextual input, i.e. does this user even have access to this part of the schema which informs how the cache key looks.

In terms of parsing, I am not sure yet how a parse() function cache would be user dependent, but the subject of caching overall is complex and there may be a small bit or a great deal that I am missing.

In terms of validation, I can definitely imagine user-specific validation rules. These cache objects, however, are service-supplied, with the service able to provide custom functions that have all the requisite information if there are indeed different user-facing requirements.

I would prefer us altering the signature as suggested in the issue and discuss this on existing PR's

I am not comfortable with artificially changing the return type of these functions. I outlined a different approach a long while back on the linked issue (#3421 (comment)) which I framed at the time as a way to help in a non-breaking way, but that I now prefer for more fundamental reasons.

[yaacovCR]

Closing, will possibly rework into a general pipeline function that can use the withCache wrapper or something similar.