enhance: fallback to setTimeout when request idle callback is not available

[huozhi]

leverage the existing simple fallback code from https://github.com/vercel/swr/pull/446/files

[sergiodxa]

LGTM, but I would just name the polyfill as requestIdleCallback, doing it will replace the window version with the polyfill for the module or define as the window version.

[shuding]

@sergiodxa is it safe to override the original window.requestIdleCallback?

[sergiodxa]

We are not directly overriding it, we are creating a function with the same name only inside the scope of the module, if you use the window object you will still have access to the original.

[huozhi]

I think here is more like a fallback instead of polyfill it since global polyfill inside library will bring side effects to the application who is using it. I should rename it.

another thing I'm not sure is that: is it safe to only use setTimeout fallback instead of rIC? insce rIC is kind of browser specific that other javascript runtime might not have. but react could have different renderers in different javascript runtime (like project ink for terminal). want to understand more about why using rIC here.

this fix sounds like won't work for RN based on the issue they mentioned (rIC polyfill inside RN doesn't work for iOS now). if use setTimeout only, the issue could be resolved.

which solution do you prefer here? keep the fallback like this and leave the polyfill to platform or we can use setTimeout to replace iRC @shuding

[sergiodxa]

This will not fix the RN issue at all, it will only add support on old browsers and environments where rIC is not available, if it's available and it doesn't work this has no way to know it.

[huozhi]

no this PR won't fix the issue indeed..I think we have few ways to do it:

1. if it's a polyfill issue on RN side, wait RN to fix it
2. user knows it might be a polyfill issue on RN side, user overrides the polyfill on their RN app with javascript (window.requestIdeCallback = fn => setTimeout(fn, 1))
3. we use setTimeout to replace the rIC, then even the polyfill have problem it can still work (so I'm not sure if this is good to do so)

thus this PR becomes an enhancement only change 😂

[sergiodxa]

I think we could let the user provide the polyfill, what do you think @huozhi @shuding? This way they could either define window.requestIdeCallback = fn => setTimeout(fn, 1) or use a package, and if they are using another library expecting rIC to exists we are not going to make them polyfill it twice.

[ties-v]

What if rIC is null?

[huozhi]

useIsomorphicLayoutEffect will execute the callback on client side only. when IS_SERVER is true it won't execute.

check the following tip under https://reactjs.org/docs/hooks-reference.html#uselayouteffect

If you use server rendering, keep in mind that neither useLayoutEffect nor useEffect can run until the JavaScript is downloaded.

[ties-v]

My bad, I just looked at the diff, not at the context around it 🙈

[cosformula]

useIsomorphicLayoutEffect will execute the callback on client side only. when IS_SERVER is true it won't execute.

check the following tip under https://reactjs.org/docs/hooks-reference.html#uselayouteffect

If you use server rendering, keep in mind that neither useLayoutEffect nor useEffect can run until the JavaScript is downloaded.

I use SWR in WeChat mini program runtime, which window is undefined and rIC is null, but useIsomorphicLayoutEffect will execute. Get an error said rIC is not a function, search the word rIC lead me to this pull request.
Maybe if(typeof latestKeyedData !== 'undefined' && rIC)) is safer than if(typeof latestKeyedData !== 'undefined' ))?