-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blinking #25
Comments
sorry, misclick |
Interesting issue, thanks for your report. How do you unmount Screen 1 and mount screen 2? It should probably be only one rendering tick. Could you please share an example of code and your helper? I would be very happy to use your solution if that can help you. |
Simple transition between routes, using react-router. Here is a minimal example: https://codesandbox.io/s/717xp22391. See how background blinks and you see "LOADER" caption when opening /screen1 and /screen2, and how smoothly color is changed when opening home page. Even with 50ms delay it is essential. Even with 10ms.
Not sure whether it's worth to post it. For now it looks a bit complicated, but it's essence is the same – do smth async before actually rendering component. Just more bells and whistles around. |
Yes, I can see it blinking. I have a similar example here. It doesn't seem to be blinking to me, could you please try? |
I didn't understand, what's the difference? It is the same example, with delay increased to 1000ms, so instead of momentary blink we can clearly see a loader while it's on screen. |
Sorry I may have misunderstood you then. |
Not exactly. I'm saying that there are some cases when loader shouldn't show up and wrapped component should be rendered synchronously. As standalone solution, everything works just as it should for now. But it becomes a problem when we have some minimal real-world requirements. Let say we should load and render list of something which doesn't change during user session; and we want to load it lazily, only when user opens corresponding page. Looks like an ideal usecase. Is it clear now? Logically component does everything we want (as developers). But as for UX we have a problem and dissatisfied users. |
Yes I understand it now, thanks.
What do you think of that solution? |
Not sure I understand... If app layout is like
Yep, in usecase shown in your docs there is nothing to do indeed. Because options => Component => {
class Reactor extends React.Component {
constructor(props) {
super(props)
this.state = { ready: options.ready(this.props) }
}
render() {
const { Loader } = options
return this.state.ready ? <Component {...this.props} /> : <Loader/>
}
async componentWillMount() {
if (!this.state.ready) {
await options.resolve(this.props)
// of course, should also check whether we're mounted now
this.setState({ ready: true })
}
}
}
} Not perfect, requires every time to remember about two places when logic changes, and as for ajax requests requires to explicitly store somewhere metadata about them (whether this resource was loaded). It's far from ideal component which does all the things itself, but it's the only working idea I have. |
A loader that doesn't make your app blink, like the following example:
|
Let say I have to screens in my application. Each screen requires some own data to be loaded before it's displayed – the task
async-reactor
is made for.Now, I'm doing transition from Screen1 to Screen2. What happens then?
Thus, user will see how first all content disappeared, then appeared after few milliseconds – even if it is very fast, it is still noticeable for an eye. It blinks, every time I'm going between screens – instead of smooth replacement of one screen with another, as React does with normal sync flow.
I wrote a helper very similar to
async-reactor
for our internal needs, and this blinking make me crazy. How do you handle this issue?The text was updated successfully, but these errors were encountered: