Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add unstable prefix to observedBits prop until its proven to work in practice #12357

Merged
merged 1 commit into from
Mar 12, 2018

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Mar 12, 2018

(Based on #12254)

During a weekly team meeting, we agreed to make this unstable until we can prove that it's a viable optimization strategy for Relay or some other library.

@acdlite acdlite force-pushed the unstableobservedbits branch from be56a88 to 04348b7 Compare March 12, 2018 20:48
@acdlite acdlite merged commit 551a076 into facebook:master Mar 12, 2018
@jaredLunde
Copy link

I know this isn't the specific use case you're looking at, but I have found the calculateChangedBits / observedBits pattern to be very useful in scaling a Viewport provider component. Using the Viewport provider/consumer model allows me to primarily 1) prevent listening to window events (scroll, size) on hundreds of components and 2) localize functions/queries related to the viewport (e.g. is this element currently visible in it?).

A problem with my first iteration of the component was that scroll events inevitably update every ViewportConsumer, including those which only listened to size changes. An obvious fix for this is to have multiple Provider/Consumers (ViewportSizeProvider, ViewportScrollProvider, etc.) but this wasn't ideal from my perspective. I also worked PureComponents into the mix which sufficed but still wasn't ideal from a usability perspective and was still extra computation.

Using observedBits as a solution, one can do <ViewportConsumer observe={SCROLL}/> or <ViewportConsumer observe={WIDTH}/>. Implementing this feature drastically improved the scroll performance of my sandbox app which contains several PopOver components listening to viewport size changes, as well as a virtualized grid of elements that only listens to scroll changes.

Here's a README of the implementation:
https://github.com/jaredLunde/render-props/tree/master/packages/viewport#props-2

I've also been playing with a use case in a personal state management library. Basically my goal is to put connections to the store into (31) buckets/shards. Instead of a state change affecting every connection, it would only affect those connections which reside in whatever 'bucket' changed. So you may still wind up in a situation where a connection needlessly gets updated, but at least it's of a limited scope rather than global.

Anyway, that's my two cents. I really love this feature conceptually, but perhaps you have some other ideas in the works.

LeonYuAng3NT pushed a commit to LeonYuAng3NT/react that referenced this pull request Mar 22, 2018
rhagigi pushed a commit to rhagigi/react that referenced this pull request Apr 19, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants