Summary:
We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting intrinsinc content size of the <Image> impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap.
And this is the step #2: Yellow Box.
<ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling.
Please, use <ImageBackground> instead of <Image> if you want to put something inside.
Reviewed By: yungsters
Differential Revision: D5139264
fbshipit-source-id: 99442107e10a321618fd34802c57a8c205ce66fb
Summary:
The lack of very clear docs on supported image formats is causing unnecessary issues (#13806).
This should mitigate and keep the issue list cleaner.
Its only a documentation change. No code changes made.
Closes https://github.com/facebook/react-native/pull/13807
Differential Revision: D5023002
Pulled By: javache
fbshipit-source-id: b1e3562ae7649cf71833b300e125966d6e832a69
Summary:
We are removing support of nesting views inside <Image> component. We decided to do this because having this feature makes supporting `intrinsinc content size` of the `<Image>` impossible; so when the transition process is complete, there will be no need to specify image size explicitly, it can be inferred from actual image bitmap.
And this is the step #0.
<ImageBackground> is very simple drop-in replacement which implements this functionality via very simple styling.
Please, use <ImageBackground> instead of <Image> if you want to put something inside.
Reviewed By: yungsters
Differential Revision: D5100021
fbshipit-source-id: 640c0fb2d1066e166d974efba39b4cfaaee7dd45
Summary:
cc hramos
Pretty sure I've hit all of the places where AppRegistry is called in CRNA-pastable examples. Let me know whether you think we need to approach the version lag differently, I figure a caveat is as natural a place to call it out as any.
If you end up finding anything else that needs tweaking before cherry picking, I'm happy to push that up here too.
Closes https://github.com/facebook/react-native/pull/13744
Differential Revision: D5071038
Pulled By: hramos
fbshipit-source-id: 4a4a6f2a73079aca627f17d75a4e4b395ecbd4a8
Summary: The xcode project for these bundled libraries should not depend on UIExplorer
Reviewed By: yungsters
Differential Revision: D4979629
fbshipit-source-id: 440b225805e9ebaf0a02b39a35c3ab9c2a83ad05
Summary:
Thanks for submitting a PR! Please read these instructions carefully:
React Native crashes hard on fresco 0.11.0 - see #13345
Repro case in #13345
Closes https://github.com/facebook/react-native/pull/13419
Differential Revision: D4913258
Pulled By: javache
fbshipit-source-id: 8beb55102e0f2d362c77698a35ea7d57fdcba48d
Summary:
I noticed I didn't get type defs anymore for react-native. Looks like it is broken since we removed the .flow file in 3e153b2a5b. To fix it we can now enable flow in react-native-implementation since it now supports properties.
**Test plan**
Tested that I get type hints when using imports from react-native in a project.
Closes https://github.com/facebook/react-native/pull/12917
Differential Revision: D4704753
Pulled By: ericvicenti
fbshipit-source-id: cf882588d7f371931de8d7861a1a6d50f6c425dc
Summary:
This is enforced for all of our internal iOS code and a common cause of import failures.
cc janicduplessis
Closes https://github.com/facebook/react-native/pull/13124
Differential Revision: D4765016
fbshipit-source-id: 7c8248c98bca0fa6bad24d5a52b666243375e0db
Summary:
Clearly state that the `getSize()` does not work for static image resources because it is assumed the developer knows their static image resource size (the reason I got from a comment on a github issue by a react native contributor).
This missing documentation cost me about 30 minutes to figure out why it didn't work for my static image resource and so I decided to update the documentation 💃
Closes https://github.com/facebook/react-native/pull/11645
Differential Revision: D4533463
Pulled By: lacker
fbshipit-source-id: 70e175ea30a5540c8a9f2a0c040585c711d82ac3
Summary:
This adds blurRadius support for <Image>, similar to iOS.
The heavy-lifting was done by lambdapioneer in the stack of diffs ending with
D3924013, we're just patching this in.
Two notes: we might need to apply two postprocessors going forward, will tackle
that in a separate diff, so we can ship this asap.
However, we need a new version of fresco to be released in order
to ship this.
Reviewed By: lexs
Differential Revision: D3936438
fbshipit-source-id: 353bf1f1120ebd5f4f8266c5a20188b41478a741
Summary:
A copy of https://github.com/facebook/react-native/pull/7791 because of our very imperfect tools that mirror the changes from pull requests in the fb monorepo. The internal Phabricator revision for #7791 is in an 'abandoned' state (by foghina probably because of changing teams) and Phabricator doesn't allow me to claim that revision and merge it. Therefore I'm creating a new one.
(It's not foghina's fault, no one probably knew about this "abandoned Phabricator revision" edge case, don't remember we hit it before.)
Will try to keep attribution (git blame) to rigdern when merging.
Closes https://github.com/facebook/react-native/pull/12448
Differential Revision: D4584743
Pulled By: mkonicek
fbshipit-source-id: 66e5b88134fca1980adc4cd8a2ff17c42e10022c
Summary:
As the task covered, we would like to update the ImageSource flow type.
Edit the flow types for ImageSource to map to the propTypes ImageSourcePropType.js
Reviewed By: mmmulani
Differential Revision: D4573836
fbshipit-source-id: ef3f5365e00b4926c75188f345811f5cfa4bfd3c
Summary: Fixes the prop type of `accessibilityLabel` in `<Image>` so that it matches that of `<View>`.
Reviewed By: fkgozali
Differential Revision: D4499103
fbshipit-source-id: 66bf3dce60bd79857849e0c46c989e7866d83d81
Summary:
This moves the `src` directory one level up and removes the `react-packager` folder. Personally, I always disliked this indirection. I'm reorganizing some things in RNP, so this seems to make sense.
Not sure if I forgot to update any paths. Can anyone advice if there are more places that need change?
Reviewed By: jeanlauliac
Differential Revision: D4487867
fbshipit-source-id: d63f9c79d6238300df9632d2e6a4e6a4196d5ccb
Summary:
In the context of an app an image exists in three resolutions on the server: `thumb` (30px) `feed` (300px) `full` (900px). When looking at an individual item a user can come either from the feed, via a permalink or from other parts of the app. This allows a situation where the `feed` image might or might not already be loaded somewhere in the app. In the detail view I want to render `thumb` with a blur (to quickly display something), then the `feed` image if it exists to have something decent to display until `full` loads. However it is quite a waste to load the `feed` image if it isn't already in cache, and will slow down the time until `full` is loaded. It is possible to track the navigation from feed->detail and that the `feed` image has actually completed loading by the feed component however as component hierarchies grow this turns into quite a lot of prop passing and bad separation of concerns.
NSURLRequests accepts a [Cache Policy](https://developer.apple.com/reference/fo
Closes https://github.com/facebook/react-native/pull/10844
Differential Revision: D4425959
Pulled By: lacker
fbshipit-source-id: 679835439c761a2fc894f56eb6d744c036cf0b49
Summary:
Xcode really sucks, per some discussion on e1577df1fd and https://developer.apple.com/library/content/technotes/tn2215/_index.html, if you use the headers phase, and mark headers in your static library as public, they will actually end up in the final package that's built and you can't submit to the app store! This changes our xcode setup to use a copy files phase instead.
I've also changed the header include path to be $(BUILT_PRODUCTS_DIR)/include, which is added to the include path by Xcode by default, so 3rd party libraries should not be impacted by these changes anymore.
Reviewed By: mkonicek
Differential Revision: D4291607
fbshipit-source-id: 969b9ebcbeb8161f85427f8c429e198d9d0fae30
Summary:
Fixes#10433
The code didn't account for the fact that cancelLoad is set by two different threads. It gets set on the URL request queue when the request completes successfully and it gets set on the UI queue during cancelation. This oversight lead to a couple of different kinds of crashes.
1. Attempt to invoke a nil function -- We check that cancelLoad is non-nil and on the next line we call it. However, cancelLoad could have been set to nil by the other thread between the time it was verified to be non-nil and the time it was called. Consequently, the program will attempt to call nil and crash.
2. Block deallocated while it's executing -- Suppose cancelLoad points to a block, it is verified to be non-nil, and it is successfully invoked. In the middle of executing the block, cancelLoad, the last reference to the block, is set to nil. This causes the block to be deallocated and its captured values to be freed. However, the block continues executing and the next time it attempts to use a captured value
Closes https://github.com/facebook/react-native/pull/11145
Differential Revision: D4261499
Pulled By: javache
fbshipit-source-id: 46424c6dd8cfa085cef32d945308de07798040bc
Summary:
Looks like the native Image implementation used to treat old `image!` images slightly differently. This diff restores that behavior for `nativeImageSource`.
{F65080365}
Reviewed By: mmmulani
Differential Revision: D4240506
fbshipit-source-id: d8d39216f86df32e0614d7cdc95df2148c85077a
Summary:
This removes support for `require('image!…')`, which has been deprecated for a long time.
It is still possible to use images that are already bundled by the native app using the `nativeImageSource` module.
Check http://facebook.github.io/react-native/docs/images.html for detailed documentation.
Reviewed By: matryoshcow
Differential Revision: D4231208
fbshipit-source-id: 05ec4c1ca0fabdc3fbb652f8ad1acdf240a67955
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: Correct header import paths, update podspec so we point at the copy in ReactCommon (and can eventually remove the copy under React)
Reviewed By: astreet
Differential Revision: D4204501
fbshipit-source-id: e979a010092f025b2cdc289e1e5f22fc7b65a8d1
Summary: The goal is to replace `require('image!...')` with an API that communicates better of what's going on under the hood.
Reviewed By: yungsters, fkgozali
Differential Revision: D4186241
fbshipit-source-id: b764588dbbd9494dd6905b2346e3274b575a9644
Summary:
When building a native component which takes an image reference as a prop, `resolveAssetSource` needs to be called on the image reference. If this isn't done, the native component may receive the opaque type returned by `require` (e.g. `require('./foo.png')`) which is useless to the native component. `resolveAssetSource` is used by builtin components that take image references such as `Image`, `WebView` and `MapView`.
This change makes `resolveAssetSource` public so that third-party native components can correctly handle image references.
**Test plan (required)**
Verified that `Image.resolveAssetSource` works in a test app. Also, my team is using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10904
Differential Revision: D4177803
Pulled By: ericvicenti
fbshipit-source-id: ffc511b9340325f7d1111002309cd8558ab8e6b0
Summary:
iOS supports an Image onError event. Android was firing the event but it was never reaching JavaScript because Android didn't include this event in `getExportedCustomDirectEventTypeConstants`.
**Test plan (required)**
Verified that the `onError` event now fires in a test app.
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10902
Differential Revision: D4180149
Pulled By: ericvicenti
fbshipit-source-id: 4bf0b9aa7dc221d838d7b6b3e88bb47196dcadef
Valentin Shergin
Francisco Sales
Jean Regisser
Adam Perry
Pieter De Baets
Brian Vaughn
Eric Vicenti
Jean Lauliac
Steffen Forkmann
Janic Duplessis
Ashwin Bharambe
Mohammed
Jeff Morrison
Ludo Fardel
Mathieu Baudet
Martin Konicek
Aaron Chiu
Charles Chen
Tim Yung
Christoph Pojer
Koen Punt
Peter Salanki
Spencer Ahrens
Drew Volz
Mehdi Mulani
Alan Norbauer
Pieter De Baets
Adam Comella
Alex Kotliarskyi
David Aurelio
AgtLucas
Adam Comella
Fred Liu
Cristian Carlesso
