ROADMAP

Below you can see the plan for this library, the plan starts with creating a very big release, after which API should be more stable. Then releases will be smaller until we reach 1.0. Why is next release so big? Because I did not want to make breaking changes all the time and I designed everything in my head first so that I could fit most/all breaking changes only in the next release, then focusing only on adding stuff.

Tasks for the next release:

• simplified action callbacks like getData, revertData, updateDataOptimistic, now they will receive data directly, and no matter whether using FSA or not
• removed internal networkReducer state, now it is a pure function, thx to this time travel will work and API can be simplified, we can use closures in request actions and values directly like requestKey
• getRequestKey renamed to requestKey, u just pass value not callback anymore, and moved out of mutations to meta directly, it will be also used for queries, not only for mutations
• requestsReducer will be removed, only networkReducer will be available, because this will give me powers to create more features plus supporting both ways is very confusing and hard to explain, for instance https://github.com/klis87/redux-saga-requests/issues/305 , networkReducer will be flexible though, u shouldnt miss any of requestsReducer features really
• refactor drivers to cancellable promises (with .cancel to support requests aborts)
• standardized successful responses, no matter you use driver directly, sendRequest, promiseMiddleware response, reducer, you get the very same response, for now containing data, but headers, status or more will be added in the future, albeit personally I use only response.data anyway most of the time. This had to be done to make it possible to support caching and SSR and in the future data persisting in localStorage all at the same time
• added automatic normalisation/denormalisation prototype, similar to Apollo but usable for any API, including REST
• getQuery and getMutations refactored from selector creators as optimised selectors, which is needed for good performance for denormalisation, and also using selectors for the same request type in multiple places will reuse the cache, again improving performance and also memory consumption
• support requestKey for queries and flatten mutation state in reducer with defined requestKey
• add requestSize key to automatically clear more requests of the same type than defined size, this will replace cacheSize
• synchronize cache with new API and made it work with mutations
• synchronize server side rendering middleware with the new API
• add handleRequests helper, which will simplify project usage, it will get config object and return middlewares (no need to document what order of middlewares is required etc), networkReducer and sagas, possibly even hide saga creation if someone doesnt use redux-saga in the app
• add some configuration to automatic normalisation, like callback to generate unique entity key etc
• rewrite examples to new API
• rewrite docs to new API

Tasks before 1.0:

Help wanted:

• add promise driver, see #244
• update mock driver so mock response will be defined inside action
• write docs in Docasaurus
• trying to get rid of regenerator-runtime from all/several packages

Advice wanted:

• add config clearDataOnError etc, see #319
• rething promise middleware response, preferably to handle all cases (success, error, abort) as resolved promise to prevent unhandle rejection promise warning, see #253
• add more things to success response,like status, header, maybe even allow it to be extended, see #320

Other tasks:

• before 1.0 ideally remove redux-saga dependency, I hope that all things can be actually implemented quite easily without sagas, with promises and redux middlewares, of course it will still be possible to use sagas with this library thx to promise middleware and putResolve for example, related to #276
• add loaded prop to query object, as without it it is not possible to know whether data is empty as request was not dispatched yet or because it is truly empty, this will also prevent flickering if requests is dispatched for the 1st time after component is rendered
• reset actions, which will reset a query state and abort pending requests if any
• rethink SSR and document it better, sometimes additional SSR middlewares might be even redundant when using with reduxFirstRouter for example
• simplify interceptors composing
• add onSuccess, onError, onAbort, onRequest keys to action.meta, this will help collocating all the logic in 1 place, inside actions
• add meta.cacheKey to declaratively invalidate cache
• prepare 1 big showcase example, with Material-ui probably to make it look nice and showing real app problems
• blog series on Medium introducing problems this library tries to solve

Tasks after 1.0:

Help wanted:

• rewrite some normalisation functions from recursive function to function with loops to improve performance and prevent theoretical possibility to run into stackoverflow, see #317
• add selector creators helpers, which could merge queries/mutations etc
• extra things for graphql driver, like client-side directives
• bundle UMD with rollup, good for marketing to reduce kbs 😃
• fetch driver should be as easy to use as axios (it is not as u need to worry about json responses inside config) and actually recommended by default, as it is standard and doesnt require any additional lib (apart from polyfills for some browsers for now)
• add polling, see #418

Advice wanted:

• add some actions and/or auto mechanism to clean normalizedData, see #318

Other tasks:

• add throthling/debouncing support
• add attachToRequest action, which will return promise of any current request of a given type if it exists
• React suspence/error support, so u can catch those states any level up in component tree
• local persistence support, allowing to create offline apps
• subscriptions, it could be separate lib but graphql driver has subscriptions, so maybe it would be good to have it here built-in too

[klis87]

@iwan-uschka Actually, when I think about it, this could really be implemented as a totally different middleware, thx for the suggestion! Hence, this is a perfect candidate for Help wanted! See https://github.com/klis87/redux-requests/issues/418 for details

[strdr4605]

@klis87 I asked a friend to create a logo for this package: