Summary:
The overflow prop needs to be set on the shadow view so that it can make its way into the layout engine. In some situations, the value of the overflow prop affects the calculations of the layout engine.
**Test plan (required)**
Verified in a test app that the `overflow` prop makes its way into the layout engine. Also, my team's app is currently using this change.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/9659
Differential Revision: D3790552
fbshipit-source-id: 61513ece63ae214f48c6cb6f40fb29757a0ac706
Summary:
Consistently namespace all of css-layout's public C API with "CSS". The only function that needed to be renamed was isUndefined, which I renamed to CSSValueIsUndefined.
Fixes#210.
Closes https://github.com/facebook/css-layout/pull/211
Reviewed By: lucasr
Differential Revision: D3674922
Pulled By: emilsjolander
fbshipit-source-id: 1752f477bde45586db112fe2654d0404cc52e1d1
Summary:
Sometimes is handy to check if a React node is a descendant of another node or not. For instance, I want to check if the focused `TextInput` is descendant of an specific `ScrollView`:
```js
const currentlyFocusedField = TextInput.State.currentlyFocusedField()
UIManager.viewIsAncestorOf(
currentlyFocusedField,
this.getInnerViewNode(),
(isAncestor) => {
if (isAncestor) {
console.log('The focused field is a descendant of this ScrollView!')
}
}
)
```
This function uses the same strategy as the `measureLayout` method to check if one node is an ancestor of other node. As the `measureLayout` method, this is performed outside the main thread.
By now I've only implemented the iOS version and its tests, but if this function is going to be merged I'll implement the Android version too. I have objc experience but no Java or Android, so I prefer to validate this functionality before jumping into developing the Android part.
Closes https://github.com/facebook/react-native/pull/7876
Differential Revision: D3662045
Pulled By: javache
fbshipit-source-id: b9668e8ea94fd01db76651f16243926cf9c2566f
Summary:
The make current RCTShadowView support RTL layout.
Two changes I made:
1 Change all left/right to start/end for margin, padding, boarder and position
2 Change the paddingAsInsets to support RTL
Reviewed By: majak
Differential Revision: D3548002
fbshipit-source-id: 15cc5228d2d28d0e12a7147daf57967e5b87ee63
Summary: RCTShadowText currently overrides a couple methods from RCTShadowView to reset the count of the cssNode children to 0. This diff instead moves that logic into RCTShadowView behind a configurable flag making it easier to reason about.
Reviewed By: javache
Differential Revision: D3586434
fbshipit-source-id: 4389a8119dc49e3fc4357174c87c0c69287ae385
Summary: fillCSSNode was only ever used in RCTShadowView to set the child count which is already performed in insert/remove subview calls and in RCTShadowText is was used to set the measure function which can be done in the initializer instead.
Reviewed By: majak, javache
Differential Revision: D3586418
fbshipit-source-id: de2155daf0f1702c8977bf23183a3b6a650d016b
Summary: Converted the zIndex property on iOS to NSInteger instead of double. This is consistent with the CSS spec, and helps to simplify the Android implementation.
Reviewed By: javache
Differential Revision: D3411491
fbshipit-source-id: 902ebc29aac39a65f7e8707a28607655f9f5052c
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
Summary:
This diff refactors the view update process into two stages:
1. The `reactSubviews` array is set, whose order matches the order of the JS components and shadowView components, as specified by the UIManager.
2. The `didUpdateReactSubviews` method is called, which actually inserts the reactSubviews into the view hierarchy.
This simplifies a lot of the hacks we had for special-case treatment of subviews: In many cases we don't want to actually insert `reactSubviews` into the parentView, and we had a bunch of component-specific solutions for that (typically overriding all of the reactSubviews methods to store views in an array). Now, we can simply override the `didUpdateReactSubviews` method for those views to do nothing, or do something different.
Reviewed By: wwjholmes
Differential Revision: D3396594
fbshipit-source-id: 92fc56fd31db0cfc66aac3d1634a4d4ae3903085
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Reviewed By: javache
Differential Revision: D3365373
Pulled By: nicklockwood
fbshipit-source-id: 66d149eb80c5c6725311e1e46d7323eec086ce64
Summary:
Previously, only Text and Image could be nested within Text. Now, any
view can be nested within Text. One restriction of this feature is
that developers must give inline views a width and a height via
the style prop.
Previously, inline Images were supported by using iOS's built-in support
for rendering images with an NSAttributedString via NSTextAttachment.
However, NSAttributedString doesn't support rendering arbitrary views.
This change adds support for nesting views within Text by creating one
NSTextAttachment per inline view. The NSTextAttachments act as placeholders.
They are set to be the size of the corresponding view. After the text is
laid out, we query the text system to find out where it has positioned each
NSTextAttachment. We then position the views to be at those locations.
This commit also contains a change in `RCTShadowText.m`
`_setParagraphStyleOnAttributedString:heightOfTallestSubview:`. It now only sets
`lineHeight`, `textAlign`, and `writingDirection` when they've actua
Closes https://github.com/facebook/react-native/pull/7304
Differential Revision: D3269333
Pulled By: nicklockwood
fbshipit-source-id: 2b59f1c5445a4012f9c29df9f10f5010060ea517
Summary:Update to latest master version of css-layout. Update integration in RCTShadow(Root)View to match.
This solves the issue with items not strechting vertically in column layouts (https://github.com/facebook/css-layout/issues/127)
Reviewed By: vjeux
Differential Revision: D3120699
fb-gh-sync-id: beba162e1255d3527e1160e9bd414a712cb10713
fbshipit-source-id: beba162e1255d3527e1160e9bd414a712cb10713
Summary:It was hard to understand which parts of the shadowview API are designed to be called only on the root view, and which were applicable to any view.
This diff extracts rootview-specific logic out into a new RCTRootShadowView class.
Reviewed By: majak
Differential Revision: D3063905
fb-gh-sync-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
shipit-source-id: ef890cddfd7625fbd4bf5454314b441acdb03ac8
Summary:The UICollectionView example is actually my use-case, which is discussed in a
bit more detail [here](https://github.com/alloy/ReactNativeExperiments/issues/2).
----
This is useful when wrapping native iOS components that determine their
own suggested size and which would be too hard/unnecessary to replicate
in the shadow view. For instance a `UICollectionView` that after layout
will update its `contentSize`, which could be used to suggest a size to
the shadow view.
The reason for adding it to -[RCTShadowView setFrame:] is mainly so it
can be used via the existing -[RCTUIManager setFrame:forView:] API and
because it might not be a feature you want to expose too prominently.
An origin of `{ NAN, NAN }` is used as a sentinel to indicate that the
frame should be used as a size suggestion. The size portion of the rect
may contain a `NAN` to skip that dimension or a suggested value for the
dimension which will be used if no explicit styling has been assigned.
Examples:
* Without any expl
Closes https://github.com/facebook/react-native/pull/6114
Differential Revision: D2994796
Pulled By: nicklockwood
fb-gh-sync-id: 6dd3dd86a352ca7d31a0da38bc38a2859ed0a410
shipit-source-id: 6dd3dd86a352ca7d31a0da38bc38a2859ed0a410
Summary:
An initial implementation was done on css-layout but isn't working correctly on many cases. The binding from React Native has been removed a long time ago. Let's not confuse people and remove it from the docs :)
Closes https://github.com/facebook/react-native/pull/5522
Reviewed By: svcscm
Differential Revision: D2859665
Pulled By: vjeux
fb-gh-sync-id: 4aa008dd93a6cea6b79a7bce444c94148791eee4
Summary:
public
Fixed some Xcode warnings, and added some missing UIResponder methods to make the behavior of RCTTextView more self-consistent.
Reviewed By: javache
Differential Revision: D2712250
fb-gh-sync-id: d30038500194d7a5262d9e77d516c65d836a4420
Summary: There is no point in using `updateLayout` when we have `didSetProps`.
The only a bit risky part is calling `dirtyLayout` in `setFrame:forView:` instead of `updateLayout`,
but since setting frame shouldn't really change border/margin/padding it should be ok.
Depends on D2699512.
public
Reviewed By: nicklockwood
Differential Revision: D2700012
fb-gh-sync-id: a7c33b3b4e3ddc195bebebb8b03934131af016fb
Summary: public
Added lightweight genarics annotations to make the code more readable and help the compiler catch bugs.
Fixed some type bugs and improved bridge validation in a few places.
Reviewed By: javache
Differential Revision: D2600189
fb-gh-sync-id: f81e22f2cdc107bf8d0b15deec6d5b83aacc5b56
Emil Sjolander
Dustin Shahidehpour
Mehdi Mulani
Pieter De Baets
Adam Comella
James Ide
alvaromb
Mengjue Wang
Wenjing Wang
Skotch Vail
Nick Lockwood
Eloy Durán
Christopher Chedeau
Martin Kralik
rocman
Pawel Sienkowski
Aaron Chiu