react-infinite-scroll-component icon indicating copy to clipboard operation
react-infinite-scroll-component copied to clipboard

actionTriggered,showLoader reset

Open ThomasWhyne opened this issue 5 years ago • 2 comments

It seems that in UNSAFE_componentWillReceiveProps, key and dataLength diffing was the only way to detect whether states listed above should be reset.

This comes with the assumption that each data fetching would be done successfully and eventually result in data item increment or key change,.

While this is sometimes untrue since it occurred to me that when there are more data to be loaded, yet due to poor network condition or some other reasons, my data fetching was not done properly( just occasionally fails ). props,states and property like dataLength,showLoader ,actionTriggered are in consequence maintained in an on-progress condition( I intended to keep previous data ), thus further retries wouldn't be triggered anymore.

I tried to refresh the key passed down to the component after my request failed, but this would result in continuous key refresh as atBottom stays true, otherwise manual key diffing seems to be implicit and error prone.

Is there any necessity triggering a fallback method after next was executed to force reset?

ThomasWhyne avatar Dec 25 '19 17:12 ThomasWhyne

This is a known issue. There was a feature which used to reset the actionTriggered flag when user would scroll up. Assuming if the next call failed and user continues to see the loading... message he would scroll up and then down again. But somehow this for removed. I'm up for adding it again. PRs welcome too!

This acted as an escape hatch when the API call fails. Ideally the next function should've been modelled as a promise and we could then hatch on to it and reset the parama when it failed/succeeded or in finally block.

On Wed, 25 Dec, 2019, 11:25 pm ThomasWhyne, [email protected] wrote:

It seems that in UNSAFE_componentWillReceiveProps, key and dataLength diffing was the only way to detect whether states listed above should be reset.

This comes with the assumption that each data fetching would be done successfully and eventually result in data item increment or key change,.

While this is sometimes untrue since it occurred to me that when there are more data to be loaded, yet due to poor network condition or some other reasons, my data fetching was not done properly( just occasionally fails ). props,states and property like dataLength,showLoader ,actionTriggered are in consequence maintained in an on-progress condition( I intended to keep previous data ), thus further retries wouldn't be triggered anymore.

I tried to refresh the key passed down to the component after my request failed, but this would result in continuous key refresh as atBottom stays true, otherwise manual key diffing seems to be implicit and error prone.

Is there any necessity triggering a fallback method after next was executed to force reset?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ankeetmaini/react-infinite-scroll-component/issues/165?email_source=notifications&email_token=ABSYHF2EVRZUCHDFHGJTCFLQ2ONALA5CNFSM4J7F56K2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ICT5XBA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSYHFY4I3YPVMROQ5UXO53Q2ONALANCNFSM4J7F56KQ .

ankeetmaini avatar Dec 26 '19 07:12 ankeetmaini

Assuming if the next call failed and user continues to see the loading... message

Yes, thats what happened right now. Is there any workaround/solution @ankeetmaini ?

ahmadichsan avatar May 03 '21 15:05 ahmadichsan