feat: rename MockProvider to CustomProvider and expose it

[varl]

Alternative to #7.

Not sure if I prefer StaticDataProvider or OfflineDataProvider. Looking at the code I think Static makes more sense, as I was doing the change Offline made me think that it insinuates to be used with e.g. local storage.

[amcgee]

I think I prefer Static to Offline as well, though since it supports functional request resolvers it's not exactly either (you could make a custom resolver which fetches from a server, technically). Maybe we want the name to imply the intended use though, in which case I think static is fine. CustomDataProvider or ManualDataProvider are other options.

[amcgee]

Definitely prefer this over #7 though, nice!

[varl]

Prodiver 🤣

[varl]

I think I prefer CustomDataProvider.

[varl]

There's some TS syntax (I think?) that's problematic for the code style:

[ERROR] Formatting failed. services/data/src/context/makeCustomContext.test.js

{ SyntaxError: Unexpected token, expected "," (48:24)
  46 |     it('Should throw if custom data is something crazy like a bigint', async () => {
  47 |         const customData = {
> 48 |             test: null as any,
     |                        ^

Everything passes, it just fails to format this one file.

[varl]

Renamed to Custom.

[amcgee]

Everything passes, it just fails to format this one file.

Yeah that's TS syntax. I had to do something a tiny bit nasty to test the should-be-impossible case (otherwise TS prevents passing invalid data). Will take a look quickly today.

[varl]

Everything passes, it just fails to format this one file.

Yeah that's TS syntax. I had to do something a tiny bit nasty to test the should-be-impossible case (otherwise TS prevents passing invalid data). Will take a look quickly today.

So that case is impossible if one uses TS to consume the library, but for a consumer built in JS it might trigger the impossible case?

[amcgee]

Everything passes, it just fails to format this one file.

Yeah that's TS syntax. I had to do something a tiny bit nasty to test the should-be-impossible case (otherwise TS prevents passing invalid data). Will take a look quickly today.

So that case is impossible if one uses TS to consume the library, but for a consumer built in JS it might trigger the impossible case?

Believe so. I'll look into making the test file .js instead

[varl]

@amcgee OK, good to know. Either way it's like this on master too, so up to you if you want to do it on this branch or a new one.

[amcgee]

@varl so the issue was actually that the test file was .js, not .ts so the formatting failed when it saw typescript syntax. I changed it to .ts and everything works. I also made a tiny update to the helper function name (resolveCustom => resolveCustomResource).

LGTM, thanks for putting it together, merging!

[varl]

@amcgee oh, nice!

[dhis2-bot]

🎉 This PR is included in version 1.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀