Summary:
To make React Native play nicely with our internal build infrastructure we need to properly namespace all of our header includes.
Where previously you could do `#import "RCTBridge.h"`, you must now write this as `#import <React/RCTBridge.h>`. If your xcode project still has a custom header include path, both variants will likely continue to work, but for new projects, we're defaulting the header include path to `$(BUILT_PRODUCTS_DIR)/usr/local/include`, where the React and CSSLayout targets will copy a subset of headers too. To make Xcode copy headers phase work properly, you may need to add React as an explicit dependency to your app's scheme and disable "parallelize build".
Reviewed By: mmmulani
Differential Revision: D4213120
fbshipit-source-id: 84a32a4b250c27699e6795f43584f13d594a9a82
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:**Motivation**
Multiple instances of `Text` inside a `ListView` is a bad idea for the performance of the app.
When you create 1000 elements and you scroll through the list it is really slow and laggy because the `NSTextStorage`, which is the backbone of the `RCTText` element, will set more than 1,000 times and also the method `setNeedsDisplay` is called multiple times. This will causes huge memory problems and the app crashes.
With this commit I check in `RCTText` if the `NSTextStorage` differs from the old value. If yes then set it otherwise don't set the `NSTextStorage`. This will prevent to call `setNeedsDisplay` when not really needed.
Gist with sample app to show behavior can be found here: https://gist.github.com/bpoetzschke/28a17969c6aa54219e18
Closes https://github.com/facebook/react-native/pull/6341
Differential Revision: D3035485
Pulled By: nicklockwood
fb-gh-sync-id: 181f01b7f87f765dbb01a4ad3196fc40f9d50694
shipit-source-id: 181f01b7f87f765dbb01a4ad3196fc40f9d50694
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
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
Summary:
Previously the text highlight overlay did not take padding into account in its positioning, so it would be misaligned for padded text. This fixes that.
Summary:
This diff implements highlighting of tapped text subranges for the iOS `<Text>` component, styled to match how iOS webkit views highlight links (translucent grey overlay with rounded corners).
Highlighting is enabled by default for any `<Text>` component which has an onPress handler. To disable the highlight, add `suppressHighlighting={true}` to the component props.
Summary:
@public
This fixes an issue with the containerBackgroundColor property of `<Text>` nodes, where containerBackgroundColor was being overridden by the backgroundColor. I also fixed up the example so that it demonstrates the feature more clearly.
Test Plan:
* Check UIExplorer text example
* Run Catalyst snapshot tests and check MAdMan, Groups
Summary:
Fixes#979.
Previously, a Text whose width is determined automatically (as opposed to set by a container) would position the text incorrectly after an update to the text *if* the text's width did not change (i.e., when changing only digits in a font with tabular numbers).
Every time RCTShadowText's RCTMeasure runs, it sets the text container's size to be the maximum allowed size for the text. When RCTText's drawRect is called later, it relied on layoutSubviews having been called to set the text container's size back to the proper width. But if RCTMeasure returned the same dimensions as last time, then RCTText's frame wasn't reset and so layoutSubviews was never re-called. With this change, we set the textContainer's size each time we draw the text.
We could also fix this by using a different NSTextContainer instance in RCTMeasure. Not sure what the pros and cons of that are.
Closes https://github.com/facebook/react-native/pull/989
Github Author: Ben Alpert <balpert@fb.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
For a very simple view I was observing that the text background was black and had to manually be set to transparent. This ensures that text nodes have a transparent background by default.
Closes https://github.com/facebook/react-native/pull/256
Github Author: James Ide <ide@jameside.com>
Test Plan:
This example component no longer renders what looks like a black block, and instead displays legible text.
var Example = React.createClass({
render: function() {
return (
<View style={styles.container}>
<Text>hello</Text>
</View>
);
},
});
var styles = StyleSheet.create({
container: {
flex: 1,
},
};
Pieter De Baets
Valentin Shergin
tfallon@mail.depaul.edu
Nick Lockwood
Adam Comella
Björn Pötzschke
Alex Akers
Georgiy Kassabli
Ben Alpert
James Ide
guru inamdar
Tadeu Zagallo
Christopher Chedeau
Spencer Ahrens
