Turn most types into interfaces

[denis-rossati]

Summary

This PR changes most types to be interfaces, thus leveraging the extensibility of the library.

---

Yet, there some types left in the code:

I couldn't manage to turn callbacks or primitives into interfaces:

• InterpreterResult
• HeaderInterpreter
• KeyGenerator
• StaleIfErrorPredicate
• CacheUpdateFn
• CacheUpdateRecord

I haven't found a way to create an equivalent interface to these types, mostly because you can't extend an Excludes<>, Partial<> or a set of union types:

• StorageValue *
• NotEmptyStorageValue
• LoadingStorageValue *
• CachePredicate

Some of them I thought to be better as a type, but please let me know if I'm wrong

• MaybePromise
• RequestInterceptor **
• ResponseInterceptor **

*The value in these cases are all interfaces, so I guess it's fine

**Even if I turned these into interfaces, the ESLint claimed that I should not extend only one interface without any adition, since it will be some sort of copy of the extended interface

---

Closes #606

[denis-rossati]

@arthurfiorette can you provide an example of how can I help regarding "Also, clarify how to extend axios-cache-interceptor types documentation"? For me it's not very clear how the lib deals with this communication

[codecov]

Codecov Report

Merging #615 (f6e8dff) into main (998e96c) will not change coverage.
Report is 7 commits behind head on main.
The diff coverage is n/a.

❗ Current head f6e8dff differs from pull request most recent head de28c0c. Consider uploading reports for the commit de28c0c to get more accurate results

@@            Coverage Diff            @@
##              main      #615   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           17        17           
  Lines          578       578           
  Branches       190       190           
=========================================
  Hits           578       578           

Files Changed	Coverage Δ
src/cache/create.ts	100.00% <ø> (ø)
src/interceptors/util.ts	100.00% <ø> (ø)
src/storage/build.ts	100.00% <ø> (ø)
src/storage/memory.ts	100.00% <ø> (ø)

[arthurfiorette]

Thanks for your work!

You forgot this one:

axios-cache-interceptor/src/cache/axios.ts

Line 21 in 998e96c

export type CacheAxiosResponse<R = any, D = any> = AxiosResponse<R, D> & {

[arthurfiorette]

@arthurfiorette can you provide an example of how can I help regarding "Also, clarify how to extend axios-cache-interceptor types documentation"? For me it's not very clear how the lib deals with this communication

As this package overrides the AxiosInstance interaface with its own types, in case of adding other interceptors or custom code which requires its own properties, its needed to do the following:

// (I typed this out of my cellphone, so IDK its 100% right)
declare module 'axios-cache-interceptor' {
  interface CacheRequestConfig<R = any, D = any> {
    myProperty: number;
  }
}

If you could just add an section on how to do the above in case you need to further customize your axios instance in general...

[arthurfiorette]

Também queria dizer que, como ex morador de pedra azul, morar na serra é loucura hahahahah

[denis-rossati]

Thanks for your work!

You forgot this one:

axios-cache-interceptor/src/cache/axios.ts

Line 21 in 998e96c

export type CacheAxiosResponse<R = any, D = any> = AxiosResponse<R, D> & {

Yep, I really forgot 😅

Upon changing locally, I noticed that would require me to add headers: AxiosRequestHeaders; to the CacheRequestConfig, like this:

export type CacheRequestConfig<R = any, D = any> = AxiosRequestConfig<D> & {
  id?: string;

  cache?: false | Partial<CacheProperties<R, D>>;

  headers: AxiosRequestHeaders; // <---- adding this property 
};

Which will also require changing some unit tests (which is weird, because axios claims this property as optional, I guess I'm missing something) is that alright?

[denis-rossati]

Também queria dizer que, como ex morador de pedra azul, morar na serra é loucura hahahahah

KKKKKKKKKKKKKKKK é outro nível mesmo

[arthurfiorette]

Which will also require changing some unit tests (which is weird, because axios claims this property as optional, I guess I'm missing something) is that alright?

Maybe you need to extend InternalCacheRequestConfig? Axios v1 is experimenting with a custom header typing / object which is breaking everywhere... So I guess we'll have to play a little with this until we get it right. Just take care to not break/force anything... this should be a non breaking change for axios-cache-interceptor users

[arthurfiorette]

Sorry for the delay, As soon as this is changed, i'll merge this PR. Thanks a lot!

[denis-rossati]

Don't worry about the delay. Thanks for the help, in the next few days when I have less work to do I want to start working on other issues :)

Also, the tests at the CI are failing but locally they're passing 🤔 I don't know how but it's possible that I broke them when updating the docs?

[arthurfiorette]

lgtm

[arthurfiorette]

Thanks @denis-rossati. Thanks for your work, probably the CI failed because you merged from main while it was broken :)