ROADMAP

[klis87]

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 How to get response data after mutation without custom reducer. #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 Could we also support promises? #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 add config clearDataOnError etc #319
• rething promise middleware response, preferably to handle all cases (success, error, abort) as resolved promise to prevent unhandle rejection promise warning, see Never rejecting promise in promise middleware #253
• add more things to success response,like status, header, maybe even allow it to be extended, see add more things to success response, like status, header, maybe even allow it to be extended #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 Remove sendRequest from API, after small adjustments yield put should be enough #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 rewrite some normalisation functions from recursive function to function with loops #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 Support short polling #418

Advice wanted:

• add some actions and/or auto mechanism to clean normalizedData, see add some actions and/or auto mechanism to clean normalizedData #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

[strdr4605]

@klis87 would be nice if you will create PRs and mentions people to comment or review. As this will make room for other contributors to understand the code and help.

Also creating simple issues that can be resolved by others will let you think more about the architecture of the packages.

One thing that I noticed while trying to debug some issues is that some functions are very complex and hard to understand. In that case, I think that probably some comments and jsdoc will be useful to keep the codebase clear for others.

Let me know if I or other contributors can help you.

[klis87]

@strdr4605 thx for the feedback

For now this is very hard as first I need to finish next release. Next release will be almost like a new major version and many features will need to be implemented with complete picture which is in my head for now. Later I think it will be possible to do things as quite independent and small tasks. Then I will think how people could help, I really appreciate the offer btw!

Could you please give me some examples of complex functions? I try to write things in the way understandable by others, but I will try to simplify those harder parts of the system but I need to know which are those.

One thing which comes to my mind is that maybe u tried to debug sagas in runtime or without sourcemaps? This is my suspicion as in another issue #311 you pasted below snippet which really is not source code but the code already compiled by Babel.

case 44:
  _context.prev = 44;
  _context.t0 = _context["catch"](28);
  // Here the eror is catched and responseError is a Error Object
  console.log({error: _context.t0});

  responseError = _context.t0;

...
...

case 57:
  // I log here the response and it is an object
  console.log({response});

  // So this "if" will break and call driver.getErrorPayload, will not be triggered
  if (response) {
     _context.next = 65;
     break;
  }

  _context.next = 60;
  return (0, _effects.call)(driver.getErrorPayload, responseError);

[strdr4605]

@klis87, I was looking at source file in Github to understand where to put logs in the compiled version.
But still functions like https://github.com/klis87/redux-saga-requests/blob/master/packages/redux-saga-requests/src/sagas/send-request.js are way too complex. Probably because it is a generator function it is hard to divide, but a least some "why" and "how" should be provided as comments.

[klis87]

@strdr4605 yes, I agree sendRequest could be a little simplified. I will make it better when trying to get rid of sagas totally, probably by replacing it with several cooperating middlewares. In the meantime after I finish next release, I will try to think of tasks I could delegate to volunteers with some hints etc.

Another way to help is to ask questions about API where it is confusing etc, I designed API so it is perfect for me, but not necessarily to others.

[strdr4605]

@klis87 As I see at this state. The package is almost ready for the next release. When it is expected? I want to see the new API. Will it be +- stable after v1.0?!

[klis87]

@strdr4605 next release will not be 1.0, but API for 1.0 will probably be mostly the same. It is possible that handleRequests won't contain sagas anymore, but actions api and driver should remain mostly similar. Thats why next release is taking so much time as I wanted this to become stable.

After 1.0 I won't do any breaking changes unless version 2.0.

Regarding time for the next release, I guess no more than 2 weeks, there is no much work to be done but I need to test everything in real apps and I am very busy with daily job.

For now, see https://github.com/klis87/redux-saga-requests/tree/dev/examples as most examples were rewritten to new API. I will let you know once TS types and docs are updated.

After next release, I will tag tasks with some hints which other people could help me with to faster release 1.0.

[klis87]

@strdr4605 new version published. Next tasks divided as help wanted, guidance wanted and others, so this is the way to help me, thx!

[strdr4605]

I will take a look and see if I have time to work on promise driver.

How about moving docs to Docusaurus. (As for example for my teammates (even I after 4+ months) will be easier to read and understand docs from Docusaurus).
I use v1 for our project and it's really nice. But maybe we can go with v2 as https://reactnavigation.org/ and others are already using alpha version.

[klis87]

@strdr4605 good idea with Docasaurus. If v2 is working, I would prefer that, especially that If I remember correctly it supports MDX

If you need some guidance with promise driver, I will gladly help too

[strdr4605]

How about also creating an npm org. Not sure about naming as you want to remove redux-saga but would be better to have:

@redux-saga-requests/core
@redux-saga-requests/axios-driver
@redux-saga-requests/fetch-driver
@redux-saga-requests/promise-driver
@redux-saga-requests/graphql-driver
@redux-saga-requests/react

[klis87]

@strdr4605 I already created redux-requests npm org several months ago :) my next step is an attempt to get rid of sagas, so I could move to @redux-requests/core etc

[strdr4605]

I would suggest adding some jsdocs that may help contributors to understand the flow of the package and the purpose of some files/functions.

Another great idea is maybe to create a diagram like Redux one. Which will explain to users and contributors how redux-requests works.

[klis87]

@strdr4605 good ideas. What about Typescript instead of jsdocs? Personally I am not fan of types as comments, I just prefer typed language.

[strdr4605]

jsdocs not for typing but for explanations, (why this function/approach).

Have you thought about moving to TypeScript? Now I work mostly with TypeScript (annotating everything some times is hard) and now hard to work on a big JS codebase.

Also making types during development is easier than after everything is done.

When we will move completely to redux-saga-requests I will try to improve some types but I would still suggest moving to TypeScript.

[klis87]

@strdr4605 Yes I did but for now I am focusing to release 1.0 ASAP, which TS wont help with as I have complete API in my head anyway, we could do that afterwards. The job which is left I split into tasks which could be done in isolation, like promise driver, but others will be just faster for me to finish than explaining the whole library to other people, documenting it and creating internal types. I would like to do everything later though.

Anyway this library has very good tests coverage, so it is quite easy to understand how things work just by looking at tests, at least I hope so :)

[strdr4605]

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

[klis87]

@strdr4605 That's look awesome, thx! I cannot wait for removing sagas and changing package name, when I will add it to README.md!

[strdr4605]

blog series on Medium introducing problems this library tries to solve

why not a separate site under klisiczynski.com or blog.klisiczynski.com?! Own your platform!!!

I created https://strdr4605.github.io/ using gatsbyjs starter in 2 days. + with google analytics, you may track people's interests!

[klis87]

@strdr4605 Thx for the advice. I thought about it, but I wanna kind of advertise this library and I expect huge amount of visitors on medium and close to 0 on my site :)

[strdr4605]

@strdr4605 Thx for the advice. I thought about it, but I wanna kind of advertise this library and I expect huge amount of visitors on medium and close to 0 on my site :)

You may also try to write a post on https://dev.to/

[iwan-uschka]

@klis87 Do you mean "polling" at Tasks after 1.0 > Other tasks:? If not:

• What is "pooling"?
• What do you think about "polling"? Do you think it could be part of this library or should be managed from the outside?

[klis87]

@iwan-uschka it was just a typo :) I meant polling, edited already.

It is on the roadmap and this will be declarative short polling. It will work like that, probably new meta.pool: integer will be added, so that request action will be repeated according to passed meta.pool.

Additionally I guess we will have stopPolling action, working like abortRequests but to cancel pollings. Probably also resetRequests will stop relevant pollings automatically (with extra flag to enable/disable this)

[iwan-uschka]

Nice! Like that :)

"polling" is part of "other tasks" and not of "Help wanted" or "Advice wanted". If you think that getting support would help in this case nevertheless, let me know.

[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 #418 for details