Skip to content
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

[RFC] Add support for listening to dimension changes on Views #777

Closed
pjjanak opened this issue Apr 9, 2015 · 9 comments
Closed

[RFC] Add support for listening to dimension changes on Views #777

pjjanak opened this issue Apr 9, 2015 · 9 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@pjjanak
Copy link

pjjanak commented Apr 9, 2015

CCing: @vjeux, @nicklockwood, @a2 - Wanted to get yours (and whoever else's) thoughts on what I'm proposing here before I dove off the deep end with it. I'm putting the tl;dr first...

Suggestion
Create RCTUIView which inherits from UIView. Have this view add a KVO (probably on bounds) to the default NSNotificationCenter. Each view would inherit from RCTUIView. On the JS side, each view would accept an additional prop onDimensionsChange which would be a callback that gets fired whenever the aforementioned KVO fires.

More Details
So to give some context this idea sprang from conversations in the IRC and the comments from PR #418. We've identified the need to be able to listen for dimension changes on the view level and initially we were thinking that adding that functionality to the RCTRootView would be sufficient to cover most people's use cases.

However @vjeux and I were talking today and came up with what might an even better solution: add this support to every view, not just the root view. In this way you could know when any view had had its dimensions changed. How that might look:

var App = React.createClass({
  render() {
    <View ref="view" onDimensionsChange={(width, height) => { ... })/>
  }
});

module.exports = App;

This would, of course, require a bit of plumbing to get everything working under the same umbrella. My thought is to add a base view that all others within the react-native hierarchy would inherit from. This view would, itself, inherit from UIView. It would have the appropriate KVO and emitters to notify whoever was listening of dimension changes and nothing else (at least for now). Then all of the existing views and future views would extend this one so they'd all have this functionality. I was thinking of calling it something like RCTUIView.

I wanted to see what others thought before I started going in and tearing up the place. So....thoughts? Ideas? Is it more than necessary?

Let me know!

@vjeux
Copy link
Contributor

vjeux commented Apr 9, 2015

If we can get that API working, I would be extremely happy! That would help a lot to workaround the layout system and help with animations. We would only lose one round-trip instead of two to know the dimensions.

<View ref="view" onDimensionsChange={(width, height) => { ... })/>

@brentvatne
Copy link
Collaborator

👍 would love to see this

@magicismight
Copy link
Contributor

It would be great

@nicklockwood
Copy link
Contributor

RCTView is already the base view used by almost all components. Probably makes sense just to add the functionality to that rather than create an new RCTUIView class.

The views that don't currently inherit from RCTView can be modified to do so. We've been talking about this option for a while anyway, as it would mean we could get rid of the category on UIView, and have a lot more flexibility to override default view behaviors.

@nicklockwood
Copy link
Contributor

Also, no need for KVO - you can simply override layoutSubviews and send the notification from there.

You wouldn't want to do this constantly for every view though, so potentially you could only send notification if the onDimensionsChange callback was set?

@vjeux
Copy link
Contributor

vjeux commented Apr 10, 2015

We can also hook it up at the layout level, in ShadowView.m we set the width/height/top/left, at this point we can check if someone is listening

@nicklockwood
Copy link
Contributor

Good point. And if we do it all in RCTShadowView, there's no need to change any of our view classes.

@pjjanak
Copy link
Author

pjjanak commented Apr 10, 2015

Oh, that would make things much easier for implementation.

@brentvatne
Copy link
Collaborator

If I'm not mistaken, this is now implemented in the form of onLayout - let me know if this doesn't solve your problem @pjjanak and I can reopen.

@facebook facebook locked as resolved and limited conversation to collaborators May 31, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

6 participants