fix: safari does not paint the fallback component

[hkhere]

While a async chunk is being loaded, safari will not paint the fallback component's dom untill the async chunk is completely loaded.

[gregberge]

Sorry the code is not correct, could you please add an issue instead to describe your problem.

[hkhere]

@gregberge issue 509

[theKashey]

Any ideas why your code fixes the problem? Single setTimeout, double setTimeout... why?

[hkhere]

@theKashey The intention is to put the requests of async chunks to other event loop phase, let safari paints the dom of the fallback component first.

It seems safari tries to do some optimizations by delaying the painting of dom if it is requesting some async chunks. But I did not really examine the source code of webkit.

I expected one setTimeout would do the job but it did not . So I tried double setTimeout and it does show the fallback component. Maybe we should/could find an more elegant solution.

[theKashey]

I've played with your example a bit, removed all possible side effects like hot-loader, even tried different code-splitting libraries, including React.lazy - everyone is affected.

Strangely why you were the first one who discovered this bug.

Wrapping initial load with timeout is more or less enough, however, there is no need to wrap suspense-related code (and you've broke something with it).

So - to resolve the problem it is enough to delay css loading via setTimeout(fn,1), and it's better to implement inside "loadAsync" method, not around it. Unfortunately my favourite "double promise" did not work at all.

Plus - such logic would make loadable a bit more stable. For example, right now it could be resolved almost synchroniously if scripts are cached using ServiceWorkers, which might lead to some unpredictable errors.

• setTimeout should be in loadAsync
• no other code should be affected
• create a test with synchroniuos thenable (see Support sync thenables for lazy() facebook/react#14626 for more details). It's actually A BIG question how loadable should handle this situation)

[theKashey]

It's also enough to call document.body.offsetLeft (cause reflow) to solve the issue.

It's also as well enough to change extract-mini-css-plugin to inject styles into body instead of head, and it would resolve the issue.

Let's first find a bug in webkit bug tracker.

[theKashey]

Ok. I am closing this PR.
Adding any timeouts of another sort of hacks there does not solve the problem:

Yes - you will see "Loading", not NO, just after it a __whole application would be frozen until css file is loaded".

I make a simple example, based of your code:

const Home = lazy(() => new Promise(resolve => setTimeout(() => resolve(import('./Home')), 1000)));
// ^^ delay import my 1s to let "loading" be displayed

const App = () => {
  const [state, setState] = useState(0);
  useEffect(
    () => {
      setInterval(() => setState(s => s + 1), 100);
    },
    []
  );
  return <div>
    <React.Suspense fallback={<Loading/>}><Home/></React.Suspense>
    {state}
     here is a counter, changing 10 times per second... 
  </div>
}

export default App;

Long story short - counted would not count.

This problem should be solved elsewhere.

[hkhere]

Adding any timeouts of another sort of hacks there does not solve the problem

This problem should be solved elsewhere.

@theKashey Totally agree. I should have just opened an issue instead of an pr with terrible code.

[theKashey]

@hkhere - you did everything right. You raised the issue, then raised attention to the problem, you led to the underlying problem discovery, and, as a result, you will get your issue fixed.