ResponseData type doesn't work as I think it should

[hendrul]

I want to have typing when dispatching (or putting) an action from a saga, something like

const response: ResponseData<typeof fetchTodos> = yield putResolve(fetchTodos())

but response got type any...
Instead my own implementation looks like this

type ResponseData<Request extends (...args: any[]) => RequestAction> = {
  data?: ReturnType<Request> extends RequestAction<infer D> ? D : never
  error?: Error  
  isAborted: boolean
  action: ReturnType<Request>
}

And it type what I expect to return from a request

[klis87]

@hendrul could you share your fetchTodos with typings? we have test for this here https://github.com/klis87/redux-requests/blob/master/packages/redux-requests/types/index.d.spec.ts#L138 and it works

I think that you need another type anyway, ResponseData https://github.com/klis87/redux-requests/blob/master/packages/redux-requests/types/index.d.ts#L105 is just to get data type, by inference from RequestAction from Data generic.

You probably need this - https://github.com/klis87/redux-requests/blob/master/packages/redux-requests/types/index.d.ts#L3 - it works with store.dispatchRequest, I am not sure though it would work with sagas, as since I use this library, I stopped using sagas and I didn't test it. If it doesn't, indeed we should add some dedicated type for sagas/and or make a hint in the docs

[hendrul]

I have been experimenting with this piece of art, exactly what I feel I was lacking in my projects. I really want this lib rise in popularity. Right now im working on refactoring a tiny proyect to propose new ways for my team to develop react redux apps. Redux sagas is on top of my refactoring, because it allows to implement user flows in a traditional structured way, and is all declarative and testable... I'm looking for the best ways and edge cases with the integration with redux-requests.
Look at this codesandbox for an example of ResponseData typing

[klis87]

I have been experimenting with this piece of art, exactly what I feel I was lacking in my projects. I really want this lib rise in popularity.

Yeah, this lib is very undervalued, and it is not new, I have been working on it since several years already! It is like my goal to perfection in declarative server communication, hence it gradually evolves. But it could be more popular with helpers like requestCreators (see #432), as imho the key is to explain benefits even not to Redux users

Right now im working on refactoring a tiny proyect to propose new ways for my team to develop react redux apps. Redux sagas is on top of my refactoring

There are 2 ways to use this libs, you can dispatch request in redux, or automatically via UI like react and helpers like useQuery. If you prefer Redux way, I recommend you also to check https://github.com/faceyspacey/redux-first-router , redux router + redux-requests in fact makes sagas redundant in my view, at least in all of my projects I worked on. All side effects you can make in interceptors and in meta.onSuccess and so on, and you gain collocation inside request actions, no need to check side-effects in separate files.

Regarding sandbox, thx! I will definitely analyze it in the upcoming time.