2015-03-26 13:32:01 +00:00
|
|
|
/**
|
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This source code is licensed under the BSD-style license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#import "UIView+React.h"
|
|
|
|
|
|
|
|
#import <objc/runtime.h>
|
|
|
|
|
|
|
|
#import "RCTAssert.h"
|
|
|
|
#import "RCTLog.h"
|
2016-03-16 17:17:09 +00:00
|
|
|
#import "RCTShadowView.h"
|
2015-03-26 13:32:01 +00:00
|
|
|
|
2016-11-11 13:22:40 +00:00
|
|
|
@interface RCTWeakObjectContainer : NSObject
|
|
|
|
@property (nonatomic, weak) id object;
|
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation RCTWeakObjectContainer
|
|
|
|
@end
|
|
|
|
|
2015-03-26 13:32:01 +00:00
|
|
|
@implementation UIView (React)
|
|
|
|
|
|
|
|
- (NSNumber *)reactTag
|
|
|
|
{
|
|
|
|
return objc_getAssociatedObject(self, _cmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)setReactTag:(NSNumber *)reactTag
|
|
|
|
{
|
Added mechanism for directly mapping JS event handlers to blocks
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
2015-09-02 12:58:10 +00:00
|
|
|
objc_setAssociatedObject(self, @selector(reactTag), reactTag, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
2015-03-26 13:32:01 +00:00
|
|
|
}
|
|
|
|
|
2016-11-11 13:22:40 +00:00
|
|
|
- (UIView *)reactSuperview
|
|
|
|
{
|
|
|
|
return [(RCTWeakObjectContainer *)objc_getAssociatedObject(self, @selector(reactSuperview)) object];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)setReactSuperview:(UIView *)reactSuperview
|
|
|
|
{
|
|
|
|
RCTWeakObjectContainer *wrapper = [RCTWeakObjectContainer new];
|
|
|
|
wrapper.object = reactSuperview;
|
|
|
|
objc_setAssociatedObject(self, @selector(reactSuperview), wrapper, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
|
|
|
}
|
|
|
|
|
2016-03-22 17:56:59 +00:00
|
|
|
#if RCT_DEV
|
2016-03-16 17:17:09 +00:00
|
|
|
|
|
|
|
- (RCTShadowView *)_DEBUG_reactShadowView
|
|
|
|
{
|
|
|
|
return objc_getAssociatedObject(self, _cmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)_DEBUG_setReactShadowView:(RCTShadowView *)shadowView
|
|
|
|
{
|
|
|
|
// Use assign to avoid keeping the shadowView alive it if no longer exists
|
|
|
|
objc_setAssociatedObject(self, @selector(_DEBUG_reactShadowView), shadowView, OBJC_ASSOCIATION_ASSIGN);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2015-03-26 13:32:01 +00:00
|
|
|
- (BOOL)isReactRootView
|
|
|
|
{
|
|
|
|
return RCTIsReactRootView(self.reactTag);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (NSNumber *)reactTagAtPoint:(CGPoint)point
|
|
|
|
{
|
|
|
|
UIView *view = [self hitTest:point withEvent:nil];
|
|
|
|
while (view && !view.reactTag) {
|
|
|
|
view = view.superview;
|
|
|
|
}
|
|
|
|
return view.reactTag;
|
|
|
|
}
|
|
|
|
|
2016-06-07 07:08:16 +00:00
|
|
|
- (NSArray<UIView *> *)reactSubviews
|
2015-03-26 13:32:01 +00:00
|
|
|
{
|
2016-06-07 07:08:16 +00:00
|
|
|
return objc_getAssociatedObject(self, _cmd);
|
2015-03-26 13:32:01 +00:00
|
|
|
}
|
|
|
|
|
2016-06-07 07:08:16 +00:00
|
|
|
- (void)insertReactSubview:(UIView *)subview atIndex:(NSInteger)atIndex
|
2016-06-06 17:27:36 +00:00
|
|
|
{
|
2016-06-07 07:08:16 +00:00
|
|
|
// We access the associated object directly here in case someone overrides
|
|
|
|
// the `reactSubviews` getter method and returns an immutable array.
|
|
|
|
NSMutableArray *subviews = objc_getAssociatedObject(self, @selector(reactSubviews));
|
|
|
|
if (!subviews) {
|
|
|
|
subviews = [NSMutableArray new];
|
|
|
|
objc_setAssociatedObject(self, @selector(reactSubviews), subviews, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
|
|
|
}
|
|
|
|
[subviews insertObject:subview atIndex:atIndex];
|
2016-11-11 13:22:40 +00:00
|
|
|
[subview setReactSuperview:self];
|
2016-06-06 23:23:32 +00:00
|
|
|
}
|
|
|
|
|
2016-06-07 07:08:16 +00:00
|
|
|
- (void)removeReactSubview:(UIView *)subview
|
2016-06-06 23:23:32 +00:00
|
|
|
{
|
2016-06-07 07:08:16 +00:00
|
|
|
// We access the associated object directly here in case someone overrides
|
|
|
|
// the `reactSubviews` getter method and returns an immutable array.
|
|
|
|
NSMutableArray *subviews = objc_getAssociatedObject(self, @selector(reactSubviews));
|
|
|
|
[subviews removeObject:subview];
|
|
|
|
[subview removeFromSuperview];
|
2016-11-11 13:22:40 +00:00
|
|
|
[subview setReactSuperview:nil];
|
2016-06-07 07:08:16 +00:00
|
|
|
}
|
|
|
|
|
2016-06-09 16:48:56 +00:00
|
|
|
- (NSInteger)reactZIndex
|
Implement CSS z-index for iOS
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
2016-06-07 14:40:25 +00:00
|
|
|
{
|
2016-06-09 16:48:56 +00:00
|
|
|
return [objc_getAssociatedObject(self, _cmd) integerValue];
|
Implement CSS z-index for iOS
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
2016-06-07 14:40:25 +00:00
|
|
|
}
|
|
|
|
|
2016-06-09 16:48:56 +00:00
|
|
|
- (void)setReactZIndex:(NSInteger)reactZIndex
|
Implement CSS z-index for iOS
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
2016-06-07 14:40:25 +00:00
|
|
|
{
|
|
|
|
objc_setAssociatedObject(self, @selector(reactZIndex), @(reactZIndex), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
|
|
|
}
|
|
|
|
|
|
|
|
- (NSArray<UIView *> *)sortedReactSubviews
|
|
|
|
{
|
|
|
|
NSArray *subviews = objc_getAssociatedObject(self, _cmd);
|
|
|
|
if (!subviews) {
|
|
|
|
// Check if sorting is required - in most cases it won't be
|
|
|
|
BOOL sortingRequired = NO;
|
|
|
|
for (UIView *subview in self.reactSubviews) {
|
|
|
|
if (subview.reactZIndex != 0) {
|
|
|
|
sortingRequired = YES;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
subviews = sortingRequired ? [self.reactSubviews sortedArrayUsingComparator:^NSComparisonResult(UIView *a, UIView *b) {
|
|
|
|
if (a.reactZIndex > b.reactZIndex) {
|
|
|
|
return NSOrderedDescending;
|
|
|
|
} else {
|
|
|
|
// ensure sorting is stable by treating equal zIndex as ascending so
|
|
|
|
// that original order is preserved
|
|
|
|
return NSOrderedAscending;
|
|
|
|
}
|
|
|
|
}] : self.reactSubviews;
|
|
|
|
objc_setAssociatedObject(self, _cmd, subviews, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
|
|
|
}
|
|
|
|
return subviews;
|
|
|
|
}
|
|
|
|
|
|
|
|
// private method, used to reset sort
|
|
|
|
- (void)clearSortedSubviews
|
|
|
|
{
|
|
|
|
objc_setAssociatedObject(self, @selector(sortedReactSubviews), nil, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
|
|
|
}
|
|
|
|
|
2016-06-07 07:08:16 +00:00
|
|
|
- (void)didUpdateReactSubviews
|
|
|
|
{
|
Implement CSS z-index for iOS
Summary:
This diff implement the CSS z-index for React Native iOS views. We've had numerous pull request for this feature, but they've all attempted to use the `layer.zPosition` property, which is problematic for two reasons:
1. zPosition only affects rendering order, not event processing order. Views with a higher zPosition will appear in front of others in the hierarchy, but won't be the first to receive touch events, and may be blocked by views that are visually behind them.
2. when using a perspective transform matrix, views with a nonzero zPosition will be rendered in a different position due to parallax, which probably isn't desirable.
See https://github.com/facebook/react-native/pull/7825 for further discussion of this problem.
So instead of using `layer.zPosition`, I've implemented this by actually adjusting the order of the subviews within their parent based on the zIndex. This can't be done on the JS side because it would affect layout, which is order-dependent, so I'm doing it inside the view itself.
It works as follows:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. `didUpdateReactSubviews` is called, which in turn calls `sortedSubviews` (which lazily generates a sorted array of `reactSubviews` by zIndex) and inserts the result into the view.
3. If a subview is added or removed, or the zIndex of any subview is changed, the previous `sortedSubviews` array is cleared and `didUpdateReactSubviews` is called again.
To demonstrate it working, I've modified the UIExplorer example from https://github.com/facebook/react-native/pull/7825
Reviewed By: javache
Differential Revision: D3365717
fbshipit-source-id: b34aa8bfad577bce023f8af5414f9b974aafd8aa
2016-06-07 14:40:25 +00:00
|
|
|
for (UIView *subview in self.sortedReactSubviews) {
|
2016-06-07 07:08:16 +00:00
|
|
|
[self addSubview:subview];
|
|
|
|
}
|
2015-03-26 13:32:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)reactSetFrame:(CGRect)frame
|
|
|
|
{
|
|
|
|
// These frames are in terms of anchorPoint = topLeft, but internally the
|
|
|
|
// views are anchorPoint = center for easier scale and rotation animations.
|
|
|
|
// Convert the frame so it works with anchorPoint = center.
|
|
|
|
CGPoint position = {CGRectGetMidX(frame), CGRectGetMidY(frame)};
|
|
|
|
CGRect bounds = {CGPointZero, frame.size};
|
|
|
|
|
|
|
|
// Avoid crashes due to nan coords
|
|
|
|
if (isnan(position.x) || isnan(position.y) ||
|
|
|
|
isnan(bounds.origin.x) || isnan(bounds.origin.y) ||
|
|
|
|
isnan(bounds.size.width) || isnan(bounds.size.height)) {
|
|
|
|
RCTLogError(@"Invalid layout for (%@)%@. position: %@. bounds: %@",
|
|
|
|
self.reactTag, self, NSStringFromCGPoint(position), NSStringFromCGRect(bounds));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-10-23 16:11:54 +00:00
|
|
|
self.center = position;
|
|
|
|
self.bounds = bounds;
|
2015-03-26 13:32:01 +00:00
|
|
|
}
|
|
|
|
|
2016-01-15 13:14:27 +00:00
|
|
|
- (void)reactSetInheritedBackgroundColor:(__unused UIColor *)inheritedBackgroundColor
|
2015-05-28 16:29:27 +00:00
|
|
|
{
|
Disable background color propagation for everything except text nodes
Summary:
public
Blending semitransparent pixels against their background is fairly a fairly expensive operation on mobile GPUs. To reduce blending, React Native has a system called "background color propagation", where the background color of parent views is automatically inherited by child views unless explicitly overridden. This means that translucent pixels can be blended directly against a known background color, avoiding the need to do this dynamically on the GPU.
In practice, this is only useful for views that do their own drawing, which is basically just `<Image/>` and `<Text/>` components, and for image components it only really matters when the image has an alpha component.
The automatic background propagation is a bit of a hack, and often does the wrong thing - for example if a view overflows its bounds, or if it overlaps a sibling, the background color will often be incorrect and need to be manually disabled. Because the only place that it provides a significant performance benefit is for text, this diff disables the behavior for everything except `<Text/>` nodes. It might still be useful for `<Image/>` nodes too, but looking through the examples in UIExplorer, the number of places where it does the wrong thing for images outnumbers the cases where it provides significant reduction in blending.
Note that this diff does not prevent you from eliminating blending on image components by manually setting an opaque background color, nor does it stop you from disabling color propagation on text components by manually setting a transparent background.
Reviewed By: javache
Differential Revision: D2811031
fb-gh-sync-id: 2eb08918c9031c582a3dd2d40e04b27a663dac82
2016-01-08 11:37:25 +00:00
|
|
|
// Does nothing by default
|
2015-05-28 16:29:27 +00:00
|
|
|
}
|
|
|
|
|
2015-07-31 18:23:29 +00:00
|
|
|
- (UIViewController *)reactViewController
|
2015-03-26 13:32:01 +00:00
|
|
|
{
|
|
|
|
id responder = [self nextResponder];
|
2015-06-24 17:14:37 +00:00
|
|
|
while (responder) {
|
|
|
|
if ([responder isKindOfClass:[UIViewController class]]) {
|
|
|
|
return responder;
|
|
|
|
}
|
|
|
|
responder = [responder nextResponder];
|
2015-03-26 13:32:01 +00:00
|
|
|
}
|
|
|
|
return nil;
|
|
|
|
}
|
|
|
|
|
2015-07-31 18:23:29 +00:00
|
|
|
- (void)reactAddControllerToClosestParent:(UIViewController *)controller
|
2015-03-26 13:32:01 +00:00
|
|
|
{
|
|
|
|
if (!controller.parentViewController) {
|
|
|
|
UIView *parentView = (UIView *)self.reactSuperview;
|
|
|
|
while (parentView) {
|
2015-07-31 18:23:29 +00:00
|
|
|
if (parentView.reactViewController) {
|
|
|
|
[parentView.reactViewController addChildViewController:controller];
|
|
|
|
[controller didMoveToParentViewController:parentView.reactViewController];
|
2015-03-26 13:32:01 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
parentView = (UIView *)parentView.reactSuperview;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Responder overrides - to be deprecated.
|
|
|
|
*/
|
|
|
|
- (void)reactWillMakeFirstResponder {};
|
|
|
|
- (void)reactDidMakeFirstResponder {};
|
2015-06-15 14:53:45 +00:00
|
|
|
- (BOOL)reactRespondsToTouch:(__unused UITouch *)touch
|
2015-03-26 13:32:01 +00:00
|
|
|
{
|
|
|
|
return YES;
|
|
|
|
}
|
|
|
|
|
2016-11-11 13:22:43 +00:00
|
|
|
#pragma mark - view clipping
|
|
|
|
|
|
|
|
/**
|
|
|
|
* How does view clipping works?
|
|
|
|
*
|
|
|
|
* Each view knows if it has clipping turned on and its closest ancestor that has clipping turned on (if any). That helps with effective clipping evaluation.
|
|
|
|
|
|
|
|
* There are four standard cases when we have to evaluate view clipping:
|
|
|
|
* 1. a view has clipping turned off:
|
|
|
|
* - we have to update NCV for its complete subtree
|
|
|
|
* - we have to add back all clipped views
|
|
|
|
* 2. a view has clipping turned on:
|
|
|
|
* - we have to update NCV for its complete subtree
|
|
|
|
* - we have to reclip it
|
|
|
|
* 3. a react subview is added:
|
|
|
|
* - we have to set it and all its subviews NCV
|
|
|
|
* - if it has NVC or clipping turned on we have to reclip it
|
|
|
|
* 4. a view is moved (new frame, tranformation, is a cell in a scrolling scrollview):
|
|
|
|
* - if it has NCV or clipping turned on we have to reclip it
|
|
|
|
*/
|
|
|
|
|
|
|
|
- (BOOL)rct_removesClippedSubviews
|
|
|
|
{
|
|
|
|
return [objc_getAssociatedObject(self, @selector(rct_removesClippedSubviews)) boolValue];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)rct_setRemovesClippedSubviews:(BOOL)removeClippedSubviews
|
|
|
|
{
|
|
|
|
objc_setAssociatedObject(self, @selector(rct_removesClippedSubviews), @(removeClippedSubviews), OBJC_ASSOCIATION_ASSIGN);
|
|
|
|
[self rct_updateSubviewsWithNextClippingView:removeClippedSubviews ? self : nil];
|
|
|
|
if (removeClippedSubviews) {
|
|
|
|
[self rct_reclip];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns a closest ancestor view which has view clipping turned on.
|
|
|
|
* `nil` is returned if there is no such view.
|
|
|
|
*/
|
|
|
|
- (UIView *)rct_nextClippingView
|
|
|
|
{
|
|
|
|
return [(RCTWeakObjectContainer *)objc_getAssociatedObject(self, @selector(rct_nextClippingView)) object];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)rct_setNextClippingView:(UIView *)rct_nextClippingView
|
|
|
|
{
|
|
|
|
RCTAssert(self != rct_nextClippingView, @"A view cannot be next clipping view for itself.");
|
|
|
|
RCTWeakObjectContainer *wrapper = [RCTWeakObjectContainer new];
|
|
|
|
wrapper.object = rct_nextClippingView;
|
|
|
|
objc_setAssociatedObject(self, @selector(rct_nextClippingView), wrapper, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Reevaluates clipping for itself and recursively for its subviews,
|
|
|
|
* going as deep as the first clipped subview is.
|
|
|
|
*
|
|
|
|
* It works like this:
|
|
|
|
* 1/ Is any of our ancestores already clipped? If yes lets do nothing.
|
|
|
|
* 2/ Get clipping rect that applies here.
|
|
|
|
* 3/ Does our bounds intersect with the rect? If no clip ourself and we are done.
|
|
|
|
* 4/ If there is an intersection make sure we are not clipped and recurse into subviews.
|
|
|
|
*
|
|
|
|
* We do 1/ and 2/ in one step by retrieving "active clip rect" (see method `activeClipRect`).
|
|
|
|
*/
|
|
|
|
- (void)rct_reclip
|
|
|
|
{
|
|
|
|
// If we are not clipping or have a view that clips us there is nothing to do.
|
|
|
|
if (!self.rct_nextClippingView && !self.rct_removesClippedSubviews) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// If we are currently clipped our active clipping rect would be null rect. That's why we ask for out superview's.
|
|
|
|
CGRect clippingRectForSuperview = self.reactSuperview ? [self.reactSuperview rct_activeClippingRect] : CGRectInfinite;
|
|
|
|
if (CGRectIsNull(clippingRectForSuperview)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!CGRectIntersectsRect(self.frame, clippingRectForSuperview)) {
|
|
|
|
// we are clipped
|
2016-11-11 13:22:44 +00:00
|
|
|
clipView(self);
|
2016-11-11 13:22:43 +00:00
|
|
|
} else {
|
|
|
|
// we are not clipped
|
|
|
|
if (!self.superview) {
|
|
|
|
// We need to make sure we keep zIndex ordering when adding back a clipped view.
|
|
|
|
NSUInteger position = 0;
|
|
|
|
for (UIView *view in self.reactSuperview.sortedReactSubviews) {
|
|
|
|
if (view.superview) {
|
|
|
|
position += 1;
|
|
|
|
}
|
|
|
|
if (view == self) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
[self.reactSuperview insertSubview:self atIndex:position];
|
|
|
|
}
|
|
|
|
// Potential optimisation: We don't have to reevaluate clipping for subviews if the whole view was visible before and is still visible now.
|
|
|
|
CGRect clipRect = [self convertRect:clippingRectForSuperview fromView:self.superview];
|
|
|
|
[self rct_clipSubviewsWithAncestralClipRect:clipRect];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* This is not the same as `reclip`, since we reevaluate clipping for all subviews at once.
|
|
|
|
* It enables us to insert the not clipped ones into right position effectively.
|
|
|
|
*/
|
|
|
|
- (void)rct_clipSubviewsWithAncestralClipRect:(CGRect)clipRect
|
|
|
|
{
|
|
|
|
UIView *lastSubview = nil;
|
|
|
|
if (self.rct_removesClippedSubviews) {
|
|
|
|
clipRect = CGRectIntersection(clipRect, self.bounds);
|
|
|
|
}
|
|
|
|
for (UIView *subview in self.sortedReactSubviews) {
|
|
|
|
if (CGRectIntersectsRect(subview.frame, clipRect)) {
|
|
|
|
if (!subview.superview) {
|
|
|
|
if (lastSubview) {
|
|
|
|
[self insertSubview:subview aboveSubview:lastSubview];
|
|
|
|
} else {
|
|
|
|
[self insertSubview:subview atIndex:0];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
lastSubview = subview;
|
|
|
|
[subview rct_clipSubviewsWithAncestralClipRect:[self convertRect:clipRect toView:subview]];
|
|
|
|
} else {
|
2016-11-11 13:22:44 +00:00
|
|
|
clipView(subview);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void clipView(UIView *view)
|
|
|
|
{
|
|
|
|
// we are clipped
|
|
|
|
if (view.superview) {
|
|
|
|
// We don't clip if react hierarchy doesn't match uiview hierarchy, since we could get into inconsistent state.
|
|
|
|
if (view.reactSuperview == view.superview) {
|
|
|
|
[view removeFromSuperview];
|
2016-11-11 13:22:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* If this view is not clipped:
|
|
|
|
* Returns a rect that is used to clip this view, in the view's coordinate space.
|
|
|
|
* If this view has clipping turned on it's bounds are accounted for in the returned clipping rect.
|
|
|
|
*
|
|
|
|
* Returns CGRectNull if this view is clipped or none of its ancestors has clipping turned on.
|
|
|
|
*/
|
|
|
|
- (CGRect)rct_activeClippingRect
|
|
|
|
{
|
|
|
|
UIView *clippingParent = self.rct_nextClippingView;
|
|
|
|
CGRect resultRect = CGRectInfinite;
|
|
|
|
|
|
|
|
if (clippingParent) {
|
|
|
|
if (![self isDescendantOfView:clippingParent]) {
|
|
|
|
return CGRectNull;
|
|
|
|
}
|
|
|
|
resultRect = [self convertRect:[clippingParent rct_activeClippingRect] fromView:clippingParent];
|
|
|
|
}
|
|
|
|
|
|
|
|
if (self.rct_removesClippedSubviews) {
|
|
|
|
resultRect = CGRectIntersection(resultRect, self.bounds);
|
|
|
|
}
|
|
|
|
|
|
|
|
return resultRect;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Sets the next clipping view for all subviews if they are not already being clipped, recursively.
|
|
|
|
* Using a `nil` clipping view will result in adding clipped subviews back.
|
|
|
|
*/
|
|
|
|
- (void)rct_updateSubviewsWithNextClippingView:(UIView *)clippingView
|
|
|
|
{
|
|
|
|
for (UIView *subview in self.sortedReactSubviews) {
|
|
|
|
if (!clippingView) {
|
|
|
|
[self addSubview:subview];
|
|
|
|
}
|
|
|
|
[subview rct_setNextClippingView:clippingView];
|
|
|
|
// We don't have to recurse if the subview either clips itself or it already has correct next clipping view set.
|
|
|
|
if (!subview.rct_removesClippedSubviews && !(subview.rct_nextClippingView == clippingView)) {
|
|
|
|
[subview rct_updateSubviewsWithNextClippingView:clippingView];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-26 13:32:01 +00:00
|
|
|
@end
|