From 81b304953284867e33b82dd4eedbe553d8b76771 Mon Sep 17 00:00:00 2001 From: Brian Vaughn Date: Tue, 21 Nov 2017 14:40:25 -0800 Subject: [PATCH] Small wording tweaks --- content/docs/faq-functions.md | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/content/docs/faq-functions.md b/content/docs/faq-functions.md index 42c93a6f..b2846355 100644 --- a/content/docs/faq-functions.md +++ b/content/docs/faq-functions.md @@ -304,9 +304,11 @@ class Searchbox extends React.Component { #### `requestAnimationFrame` throttling -[`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) is a way of queuing a function to be executed in the browser at the optimal time for rendering performance. A function that is queued with `requestAnimationFrame` will fire in the next frame. The browser will work hard to ensure that there are `60` frames per second (`60 fps`). However, if the browser is unable to it will naturally *limit* the amount of frames in a second. For example, a device might only be able to handle `30 fps` and so you will only get `30` frames in that second. Using `requestAnimationFrame` for throttling is a useful technique in that it prevents you from doing more than `60 updates` in a second. If you are doing `100` updates in a second this creates additional work for the browser that the user will not see anyway. +[`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) is a way of queuing a function to be executed in the browser at the optimal time for rendering performance. A function that is queued with `requestAnimationFrame` will fire in the next frame. The browser will work hard to ensure that there are 60 frames per second (60 fps). However, if the browser is unable to it will naturally *limit* the amount of frames in a second. For example, a device might only be able to handle 30 fps and so you will only get 30 frames in that second. Using `requestAnimationFrame` for throttling is a useful technique in that it prevents you from doing more than 60 updates in a second. If you are doing 100 updates in a second this creates additional work for the browser that the user will not see anyway. -> Using this technique will only capture the last published value in a frame. You can see an example of how this optimization works on [`MDN`](https://developer.mozilla.org/en-US/docs/Web/Events/scroll) +>**Note:** +> +>Using this technique will only capture the last published value in a frame. You can see an example of how this optimization works on [`MDN`](https://developer.mozilla.org/en-US/docs/Web/Events/scroll) ```jsx import rafSchedule from 'raf-schd'; @@ -314,31 +316,27 @@ import rafSchedule from 'raf-schd'; class ScrollListener extends React.Component { constructor(props) { super(props); + this.handleScroll = this.handleScroll.bind(this); - // create a new function that will schedule updates - this.scheduleUpdate = rafSchedule(this.emitUpdate.bind(this)); + // Create a new function to schedule updates. + this.scheduleUpdate = rafSchedule( + point => this.props.onScroll(point) + ); } handleScroll(e) { - // When we receive a scroll event, we are going to schedule an update - // If we receive many updates within a single frame duration we will - // only be publishing the latest value. - + // When we receive a scroll event, schedule an update. + // If we receive many updates within a frame, we'll only publish the latest value. this.scheduleUpdate({ x: e.clientX, y: e.clientY }); } - emitUpdate(point) { - this.props.onScroll(point); - } - componentWillUnmount() { - // As we are unmounted we can clear the next animation frame + // Cancel any pending updates since we're unmounting. this.scheduleUpdate.cancel(); } render() { - // Creating a scroll container around a big image return (