Summary:
If tracking is enabled and the sampling check passes on a scroll or layout event,
we compare the scroll offset to the layout of the rendered items. If the items don't cover
the visible area of the list, we fire an `onFillRateExceeded` call with relevant stats for
logging the event through an analytics pipeline.
The measurement methodology is a little jank because everything is async, but it seems directionally
useful for getting ballpark numbers, catching regressions, and tracking improvements.
Benchmark testing shows a ~2014 MotoX starts hitting the fill rate limit at about 2500 px / sec,
which is pretty fast scrolling.
This also reworks our frame rate stuff so we can use a shared `SceneTracking` thing and track blankness
globally.
Reviewed By: bvaughn
Differential Revision: D4806867
fbshipit-source-id: 119bf177463c8c3aa51fa13d1a9d03b1a96042aa
Summary:
This adds a flowified JS module for the FrameRateLogger native module and plugs
it into `ScrollResponder` and `AppRegistry`.
If there is no `FrameRateLogger` native module, then the function calls will be no-ops.
One major limitation is that we can't track animated/programatic scrolls because we don't
have reliable end events. Would be generally useful to add those in a followup though.
Reviewed By: fkgozali
Differential Revision: D4765694
fbshipit-source-id: f3bec771df6ac918200c1afd1a7d8b6da540a4e2
Summary: Add simple `getRegistry()` so that add can do some custom handling of the registered components, if appropriate.
Reviewed By: shergin
Differential Revision: D4550600
fbshipit-source-id: 367c66b9fddfe4cc81cbc32a7a6043215e0df666
Summary:
Simple cleanup for AppRegistry.
Also added `registerSection()` helper to mark registered components as app-specific sections. Sections can be treated in many custom ways, e.g. they could just indicate the top level tabs, or something else. A bunch of helpers are also added.
Reviewed By: yungsters
Differential Revision: D4542788
fbshipit-source-id: 07addecb78a7514e973335bca24414fd8db40997
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
For more info, see
Closes https://github.com/facebook/react-native/pull/11459
Differential Revision: D4339946
Pulled By: lacker
fbshipit-source-id: d95e7c62dbf7bf6fd2ab3739b3d64bfcbe83e24a
Pieter De Baets
周中原
Adam Perry
Spencer Ahrens
Alexey Lang
Martin Konicek
Aaron Chiu
Kevin Gozali
pedramsaleh
Tim Yung
