Unstyled components flashing in Safari

[humphreybc]

Description of problem

When using Safari, unstyled components will flash for a split second before becoming styled. This applies to the whole page on initial load as well as components that are rendered when they're opened (like dropdowns and modal dialogs).

Versions

• OS X 10.13.2
• React 16.2.0
• Safari 11.0.2
• Typestyle 1.6.0

Video

App index

import { App } from "dovetail/app";
import * as React from "react";
import * as ReactDOM from "react-dom";
import { forceRenderStyles } from "typestyle";

const container = document.getElementById("react-app");
ReactDOM.render(<App />, container);

forceRenderStyles();

[basarat]

I can see you are calling forceRenderStyles. That is exactly for preventing this unsightly flash : https://typestyle.github.io/#/core/tip-forcerenderstyles-

Suspect there are calls to typestyle.style that aren't a part of the initial render and dependent on some UI state transition / backend response / react lifecycle or something else that is time sensitive. Try moving those styles into namespaces instead of depending on React lifecycle so they are resolved before the dom gets rendered : https://typestyle.github.io/#/core/tip-code-organization

A small reproducible example would be needed if issue persists 🌹

[bradleyayers]

What do you think about using a microtask scheduler instead of RAF for style()?

[basarat]

What do you think about using a microtask scheduler instead of RAF for style()

It turns in a time war. Who wins will still be determined by how other libraries / user code etc behaves.

[bradleyayers]

It turns in a time war. Who wins will still be determined by how other libraries / user code etc behaves.

My understanding is that microtasks block the current paint (and as such are guaranteed to execute before the paint). This would guarantee that the styles are added to the DOM and incorporated into the CSSOM before the paint occurs, which would guarantee the styles introduced by a style() call would be present in the next paint.

Your point about other libraries or user code is interesting, but after mulling over it for a while I can't think of how they could interfere with this, as they can't unschedule microtasks.

In my mind the trade-offs to choose between are:

1. incur worse performance (i.e. potentially < 60fps) by forcing a DOM update before the paint, or
2. have improved performance, but with potentially broken behaviour

For me option 1 seems a little better than 2. It still gives the user the opportunity to schedule via RAF if they wish (by calling style() in a RAF callback).

[basarat]

Probably an easy fix in user code as import('./someLazyLoadedAppSection').then(forceRenderStyles). I just don't want to do anything to fix a problem I haven't experienced ¯\_(ツ)_/¯ 🌹

Quick notes:

• aphorodite uses asap: https://github.com/Khan/aphrodite/blob/a05782725aa1f273f6e470017b871a3db9fb0387/package.json#L65
• asap is a microtask wrapper : https://www.npmjs.com/package/asap
  
• aphrodite can still result in flashes Styles flicker in. Khan/aphrodite#147 < Just a quick google search, probably also because of user error or browser error and not a problem with asap

[bradleyayers]

Fair enough, thanks for the quick reply. For now user code sounds like the way to go. If other people start hitting this problem (unlikely at this point) we can revisit baking something into the library.

Regarding forceRenderStyles, does it only render styles that haven't been applied yet?

[basarat]

, does it only render styles that haven't been applied yet?

No. Just writes the styles to the tag without any smarts :

typestyle/src/internal/typestyle.ts

Line 136 in 204b423

target.textContent = this.getStyles();