You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At my company, we wanted to use Either to represent operations with potential exceptional states, but a lot of these operations are the result of async operations which return a non-Promise representation of the operation state
(I guess you could call this a representation of async state)
This representation or something like it shows up quite a lot, at least in react development scenarios (react-query, swr, apollo client, common redux patterns), and the addition of the isLoading flag makes Either difficult to use or unusable.
First we tried using Maybe<Either<L, R>>, but having to chain flatMaps on many calls was cumbersome especially for folks who were newer to functional programming.
We decided to create a type based heavily off of purify's Either but adding a Loading state, creating essentially: type AsyncResult = Left<L, R> | Right<R, L> | Loading<L, R>
(we followed the same pattern as purify source code, so the implementation actually uses classes and interfaces)
Is this something that would make sense to add to purify as a whole? I haven't seen a type like this show up in most functional programming libraries. However, ts-belt is considering adding a sum type does cover a very similar use case: AsyncDataResult: mobily/ts-belt#51
The text was updated successfully, but these errors were encountered:
In the case of react development, I would recommend using a proven library like react-query that handles not only the loading state but caching, management (refetching, invalidation) and a lot of other useful things. Even if purify provided such a data type it would always be inferior to specialized libraries.
Our use case is actually for react-query coincidentally. React-queries types don't work super well for aggregating the results of multiple async operations without a lot of extra typescript boilerplate and conditional logic. It makes sense though, I'll close this.
At my company, we wanted to use Either to represent operations with potential exceptional states, but a lot of these operations are the result of async operations which return a non-Promise representation of the operation state
e.g. a react hook returning
(I guess you could call this a representation of async state)
This representation or something like it shows up quite a lot, at least in react development scenarios (react-query, swr, apollo client, common redux patterns), and the addition of the isLoading flag makes
Either
difficult to use or unusable.First we tried using
Maybe<Either<L, R>>
, but having to chain flatMaps on many calls was cumbersome especially for folks who were newer to functional programming.We decided to create a type based heavily off of purify's
Either
but adding aLoading
state, creating essentially:type AsyncResult = Left<L, R> | Right<R, L> | Loading<L, R>
(we followed the same pattern as purify source code, so the implementation actually uses classes and interfaces)
Is this something that would make sense to add to purify as a whole? I haven't seen a type like this show up in most functional programming libraries. However, ts-belt is considering adding a sum type does cover a very similar use case:
AsyncDataResult
: mobily/ts-belt#51The text was updated successfully, but these errors were encountered: