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
Instead of having to provide the url, headers, body, etc and then that be used in fetch, it would be great if given the user the option to simply provide a promise also which is called instead.
The use case arises when you build your own clients for your backend server and want to use those, since they already incoporate your custom setup of authentication, logging, error handling etc. And you might want to use your own http client or rest client. An infact might want to use your own websocket client. Making the api generic to handle any promise leads to a lot of possibilities.
Losing all the functionality by only giving the option to use fetch therefore is not ideal.
So I would propose this api change, and if it makes sense to you then I'd be happy to make a PR.
// Adding a new prop called promise which you can provide instead of url, headers, body, etcconstcustomPromise=backend.service('/database/users').get(userId)<ReactPollingpromise={customPromise}interval={3000}// in milliseconds(ms)retryCount={3}// this is optionalonSuccess={()=>console.log('handle success')}onFailure={()=>console.log('handle failure')}// this is optionalrender={({ startPolling, stopPolling, isPolling })=>{if(isPolling){return(<div> Hello I am polling</div><Spinner/>
</div>);}else{return(<div> Hello I stopped polling</div></div>);}}}/>
// Inside the libary a one line change is made like sorunPolling(){const{ url, interval, onSuccess, onFailure, api }=this.config;const_this=this;this.poll=setTimeout(()=>{/* onSuccess would be handled by the user of service which would either return true or false * true - This means we need to continue polling * false - This means we need to stop polling */constpromise=this.props.promise ? this.props.promise : ()=>fetch(url,api)promise().then(resp=>{returnresp.json().then(data=>{if(resp.ok){returndata;}else{returnPromise.reject({status: resp.status, data });}});}).then(onSuccess).then(continuePolling=>{_this.state.isPolling&&continuePolling ? _this.runPolling() : _this.stopPolling();}).catch(error=>{if(_this.config.shouldRetry&&_this.config.retryCount>0){onFailure&&onFailure(error);_this.config.retryCount--;_this.runPolling();}else{onFailure&&onFailure(error);_this.stopPolling();}});},interval);}
Thanks for all your work on this 🎉
The text was updated successfully, but these errors were encountered:
@subodhpareek18 Sorry for the delay in replying. I have been busy with some other work.
But this looks great. I am up for getting this merged into the code. Would you like to send a PR for the same?
I also came across this requirement. Currently I'm using a "dummy" url which just responds with 200 ok as a workaround to use the polling component without having to implement it in javascript from scratch
Hey @subodhpareek18 and @masbaehr, apologies for the delay. The last couple of months have been really hectic in terms of work.
But I am hoping latest release v1.0.7 will address all your concerns.
Thank you for creating this issue and I hope the new release is helpful.
Please try it and let me know if it fixes your issue.
Here is the sandbox link which will demonstrate an example which is similar to your requirements
Instead of having to provide the url, headers, body, etc and then that be used in fetch, it would be great if given the user the option to simply provide a promise also which is called instead.
The use case arises when you build your own clients for your backend server and want to use those, since they already incoporate your custom setup of authentication, logging, error handling etc. And you might want to use your own http client or rest client. An infact might want to use your own websocket client. Making the api generic to handle any promise leads to a lot of possibilities.
Losing all the functionality by only giving the option to use fetch therefore is not ideal.
So I would propose this api change, and if it makes sense to you then I'd be happy to make a PR.
Thanks for all your work on this 🎉
The text was updated successfully, but these errors were encountered: